% Start Präambel

\documentclass[a4article,twoside,headsepline,openright,open=right]{scrartcl}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[ngerman]{babel}
\usepackage{listings}
\usepackage[babel,german=guillemets]{csquotes}
\usepackage[backend=bibtex8]{biblatex}
\usepackage{graphicx}
\lstset{breaklines=true, columns=flexible, basicstyle=\small}
%Abstände
\usepackage[top=2.5cm,bottom=2.5cm,inner=2.5cm,outer=2.5cm]{geometry}

%Seitennummer oben , ilines
\usepackage[automark]{scrpage2}
\pagestyle{scrheadings}
\ohead{\pagemark}
\ihead{\headmark}
\ofoot{}

% Zentrieren
\setlength{\oddsidemargin}{0cm}
%\setlength{\evensidemargin}{0cm}

%erste Seite muss die Nummer 4 haben. Ich nehme 3, weil erstes Blatt leer bleib(wegen dem doppelseitigen Drucken). Das Blatt muss weg.
\setcounter{page}{3}

%linespread
\linespread{1.25}

\renewcommand{\refname}{Quellenverzeichnis}
\bibliography{mybib}
\usepackage{notoccite}


% Abb. statt Abbildung
\addto\captionsngerman{
\renewcommand{\figurename}{Abb.}
}

% Text stretch
\setlength{\emergencystretch}{10em}

% Ende Präambel
\begin{document}

\cleardoublepage
%\thispagestyle{empty}

\tableofcontents
\newpage
\thispagestyle{empty}
\listoffigures

\newpage
%Falls nicht auf der rechten Seite ->
%\cleardoublepage

\section{Einleitung}
\label{Einleitung}
	Die Suche in einer großen Sammlung von Dateien kann trotz relativ guter Strukturierung zu einer aufwendigen Aktion werden. Es gibt viele Gründe, die eine Suche nach Dateien erschweren können. Unter Umständen kann eine ursprünglich gewählte Verzeichnisstruktur nicht alle Anwendungsfälle berücksichtigen, da sich diese auch mit der Zeit verändern können. So kann die Struktur mit der Zeit für bestimmte Dateien sogar unpassend werden. Ein weiteres Problem ist, dass für neue Dateien kein passender bzw. eindeutiger Platz in der Verzeichnisstruktur gefunden werden kann. Oft kann eine Datei nach der Logik der Verzeichnisstruktur nicht nur in ein, sondern in mehrere Verzeichnisse gespeichert werden. Um Datenredundanz zu vermeiden, kann eine solche Datei in einem der passenden Verzeichnisse gespeichert und in anderen Links angelegt werden oder das Problem wird schlicht ignoriert. Außerdem ist die inkonsequente Einhaltung der Namenenskonventionen beim Abspeichern ein Problem. Gerade bei Multimedia-Dateien, die von mobilen Geräten wie Digitalkameras importiert werden, treten häufig nichtssagende Dateinamen auf. Nach solchen Dateien kann man nur dann effektiv suchen, wenn ihr Pfad Informationen über ihre Semantik beinhaltet. Schließlich können Metadaten von Dateien nicht ausreichend für eine Suche sein oder komplett fehlen.
		
	Für eine bessere Suche kann man die Umstrukturierung der Verzeichnisse, die Prüfung der Einhaltung von Konventionen, das Umbenennen von Dateien, das Hinzufügen von Metadaten und andere Aktionen durchführen. Die Suche nach Dateien kann auch durch die Berücksichtigung der Semantik von Benutzeranfragen und Dateiinhalten verbessert werden. Das kann sowohl bei der gezielten als auch bei der unscharfen Suche zu besseren Ergebnissen führen.
		
	Ein Beispiel verdeutlicht die Vorteile, wenn die Semantik berücksichtigt wird. Nehmen wir an, ein Benutzer sammelt Urlaubsfotos und verwendet dafür folgende Verzeichnisstruktur:   
	\begin{lstlisting}
	.../Urlaub2010/Europa/Madrid/
	.../Urlaub2011/Europa/Spanien/
	.../Urlaub2011/USA/New-York/
	\end{lstlisting}
	
	Der Benutzer sucht nach allen Fotos, die thematisch zum Thema \emph{Spanien} passen, und benutzt dabei als Anfrage das Wort \emph{Spanien}. Vom Benutzer werden unscharfe Suchergebnisse erwartet. Es wird nur eine einfache patternbasierte Suche verwendet und nur die Dateien gefunden, die im Verzeichnis 
	\begin{lstlisting}
	.../Urlaub2011/Europa/Spanien/ 
	\end{lstlisting} 
	liegen, obwohl auch Fotos von Madrid vom Benutzer erwartet wurden. Das System kann Fotos von Madrid nicht finden, weil ihm die Hintergrundinformation darüber fehlt, dass Madrid eine spanische Stadt ist. Um ein besseres Ergebnis ohne Berücksichtigung der Semantik zu bekommen, ist eine Änderung der Verzeichnishierarchie notwendig, die das fehlende Wissen des Systems über die Städte kompensieren soll. Eine solche Änderung kann nicht immer so durchgeführt werden, dass die neue Verzeichnisstruktur dem ursprünglichen Konzept der Verzeichnisstruktur entspricht. Die bessere Alternative ist ein Suchsystem, das die Semantik der Verzeichnisnamen berücksichtigt.
	
	Ein weiteres Beispiel für den sinnvollen Einsatz der Semantik ist die gezielte Suche nach Multimediadateien. Der Inhalt von Multimediadateien wird oft mithilfe Metadaten beschrieben. Wenn die Bedeutung von Metadaten einem Suchsystem unbekannt ist, kann das dazu führen, dass bei einer patternbasierten Suche und gleichzeitig großer Anzahl von ähnlichen Tags mehrere unerwartete Dateien gefunden werden. Bei einer semantischen Suche könnten in diesem Fall viele Dateien aus der Ergebnismenge ausgeschlossen werden, wenn Metadaten eindeutiger interpretiert oder die Beziehungen zwischen Begriffen berücksichtigt werden. Besonderes bei großen Sammlungen wissenschaftlicher Multimediadateien wird die semantische Suche zu einem Werkzeug, ohne das effizientes Arbeiten kaum möglich ist.

	Ein Ansatz für die Berücksichtigung der Semantik von Dateien bei der Verwaltung und vor allem bei der Suche wird in \autocite{art:semanticFileSystemSIL} präsentiert. Die Idee besteht darin, statt einem herkömmlichen Dateisystem mit Baumstrukturen ein semantisches Dateisystem zu benutzen. In \autocite{art:semanticFileSystemSIL} wird das Dateisystem \emph{Semantics Instead of Location}(SIL) genannt. Dateien werden in diesem System nicht durch Pfade und Dateinamen beschrieben, sondern mithilfe der Schlüsselwörter, sogenannten Tags. Sie können entweder manuell angelegt oder vom Dateisystem aus den bereits existierenden standardisierten Tags extrahiert werden. Der Zugriff auf die Dateien erfolgt entweder durch die Angabe der gewünschten Tags oder durch tagbasiertes Browsing. Somit bietet dieser Ansatz Lösungen für unscharfe und für gezielte Suche. Außerdem werden die Dateieinhalte in den Vordergrund gestellt und der Benutzer wird vom Dateisystem gezwungen, Semantik von Dateien immer im Fokus zu halten und Daten zu beschreiben.

	SIL macht zwar die Suche nach Dateien effizienter und inhaltsorientierter, aber es hat gleichzeitig einige Schwächen. Erstens werden hierarchische Beziehungen zwischen Begriffen in Tags nicht berücksichtigt. Sie könnten für unscharfe Suche eingesetzt werden. Zweitens werden Synonyme und Homonyme vom System nicht erkannt. Tags beschreiben zwar die Bedeutung der Daten für Menschen, aber für SIL bleibt diese Bedeutung unbekannt. Auch \emph{nicht}-hierarchische Beziehungen zwischen Begriffen in Tags sind für das System unbekannt und können folglich auch bei der Suche nicht berücksichtigt werden. Die erwähnten Probleme können durch den Einsatz von formalen Beschreibungen der Wissensdomäne, sogenannten Ontologien, gelöst werden.
	
	Diese Arbeit bietet ein auf Basis einiger Ideen aus \autocite{art:semanticFileSystemSIL} erstelltes Konzept, das semantische Suche nach Dateien innerhalb eines herkömmlichen Dateisystems durch die Verwendung von drei Elementen ermöglicht:
\begin{enumerate}
	\item Ontologien,
	\item ontologiebasierten Tags und
	\item einer ontologiebasierten Anfragesprache.
\end{enumerate}

	Ontologien spielen dabei eine Schlüsselrolle und repräsentieren das Hintergrundwissen des Systems. Die Grenzen für die Inhaltsbeschreibung und die Suchanfragen werden durch Ontologien definiert. Das wird dadurch sichergestellt, dass Tags und Anfragen ontologiebasiert sein müssen, d.h. sie können nur in Verbindung mit existierenden Elementen einer Ontologie entstehen. Die Idee aus \autocite{art:semanticFileSystemSIL}, Tags für die Beschreibung der Dateiinhalte zu verwenden, wird übernommen und an den ontologiebasierten Einsatz angepasst. Auch die Idee standardisierte Metadaten aus Dateien zu extrahieren, um das Tagging effizienter zu machen, stammt aus \autocite{art:semanticFileSystemSIL}. Die extrahierten Metadaten werden in ontologiebasierte Tags umgewandelt.	
	
	Die Umsetzbarkeit des Konzepts soll mit Hilfe eines Prototyps überprüft werden. Dieser soll in Form einer Java-basierten Desktop-Suchanwendung realisiert werden. Im Prototyp sollen drei Komponenten implementiert werden: eine ontologiebasierte Suchkomponente, ein Editor für ontologiebasierte Tags und ein Extraktionstool für IPTC-Metadaten.
		
	Die Arbeit ist nach der Einleitung (Kapitel \ref{Einleitung}) in fünf Kapitel gegliedert.
Zuerst wird in Kapitel~\ref{Einführung in die Ontologien} eine allgemeine Einführung in das Thema \emph{Ontologie} gemacht. Ansätze und Ideen aus einigen verwandten Arbeiten zum Thema \emph{semantische Suche} werden in Kapitel \ref{Verwandte Arbeiten} vorgestellt. Das Kapitel~
\ref{Konzept der Suche} beschäftigt sich mit dem Hauptthema dieser Arbeit, dem Konzept der ontologiebasierten Suche nach Dateien. In diesem Kapitel werden Schlüsselelemente des Konzepts Ontologie, ontologiebasierte Metadaten und ontologiebasierte Anfragesprache erläutert und diskutiert. Anschließend wird in Kapitel \ref{Ontologiebasierte Suchanwendung} eine auf diesem Konzept basierende Prototyp-Anwendung zur ontologiebasierten Suche präsentiert und die Anwendbarkeit im Vergleich zur musterbasierten Suche evaluiert. Abschließend wird in Kapitel \ref{Zusammenfassung} ein zusammenfassender Überblick über die Arbeit und ihre Ergebnisse gegeben.

\newpage
\section{Einführung in Ontologien}
\label{Einführung in die Ontologien}
	Der Begriff \emph{Ontologie} stammt aus der Philosophie und ist dort als Lehre vom Sein definiert. Die Ontologie als eine philosophische Disziplin beantwortet die Frage, was es heißt, dass es etwas gibt, versucht die Welt zu kategorisieren und Beziehungen zwischen Objekten zu beschreiben. 
	
	In der Informatik wurde eine Ontologie zum ersten Mal 1993 von Thomas R. Gruber in \autocite{art:defOntology} wie folgt definiert:
\begin{quote}
\emph{An ontology is a specification of a conceptualization.}
\end{quote}
	Zwei Jahre später wurde diese Definition von Thomas R. Gruber in \autocite{art:defOntologyNext} präzisiert, indem das Wort \emph{Spezifikation} in der Definition durch \emph{explizit} und \emph{formal} eingeschränkt wurde.

	Trotz Gemeinsamkeiten zwischen dem Begriff der Ontologie innerhalb der Informatik und innerhalb der Philosophie, ist seine Bedeutung eine andere. Im Unterschied zur Philosophie ist eine Ontologie in der Informatik keine Disziplin oder Lehre, sondern eine formal beschriebene Spezifikation oder das Wissen über Konzepte einer bestimmten Domäne und ihre Beziehungen. Sie ist auch eine Kategorisierung und Beschreibung, aber das zu beschreibende Objekt ist nicht die ganze Welt, sondern nur ein Teil davon. Außerdem ist eine solche Beschreibung in der Informatik formal um maschinelle Bearbeitung zu ermöglichen.

	Grafisch kann eine Ontologie wie ein gerichteter Graph mit Kantenbewertungen dargestellt werden. Die Idee der Darstellung von Ontologien in Form semantischer Netzen geht auf Ross Quilian zurück. Er hat u Modelle des menschlichen Gedächtnisses erstellt und eine Hypothese aufgestellt, dass Begriffe und ihre Bedeutung in unserem Kopf semantische Netze bilden. Die Knoten solcher Netze repräsentieren Begriffe oder Wörter. Die Assoziationen sind Kanten. Durch die Entfernung zwischen zwei Knoten, gemessen in Anzahl der Kanten, kann man Schlüsse darüber ziehen, wie stark zwei Begriffe miteinander assoziiert sind \autocite{book:Ontologie}.

%Nutzen
	In der Informatik werden Ontologien zur Bewältigung unterschiedlicher Aufgaben herangezogen. Gruninger und Lee sehen den Nutzen von Ontologien in der Kommunikation, im automatischen Schließen und Repräsentation sowie Wiederverwendung von Wissen\autocite{art:ontologyAppAndDesign}. Dank Ontologien können Software-Systeme Daten so verarbeiten, als hätten sie Kenntnisse über die Bedeutung des Inhalts. Die zu bearbeitende Daten stellen Informationen über eigenen Inhalt bereit (Metadaten). Die in Metadaten gespeicherten Informationen müssen mit den entsprechenden Ontologie-Elementen korrespondieren, d.h. um Schlüsse zu ziehen soll die Ontologie Begriffe aus Metadaten eigenen Elementen zuordnen können.

% Semantic Web
% The Semantic Web Tim Berners-Lee: \url{http://www.scientificamerican.com/article.cfm?id=the-semantic-web&page=4}
	Großes Interesse wecken Ontologien in letzter Zeit durch die Semantic-Web-Initiative von Tim Berners-Lee und seiner Kollegen. Die Idee der Semantic-Web-Initiative besteht darin, die Semantik der Web-Dokumente mit Metadaten (\emph{tags}) zu versehen und sie durch Ableitungsregeln miteinander zu verknüpfen. Suchmaschinen und andere Anwendungen sollen die Metadaten dafür verwenden, Informationen effizient und gezielt zu finden und sie miteinander zu verbinden. Metadaten und Verknüpfungsregeln werden in Ontologien definiert\autocite{url:ontologieBegriff}.

% Ontologie Entwurf: 2 Ansätze
	Beim Entwurf von Ontologien werden zwei Ansätze angewendet: induktiver und deduktiver. Bei einem induktiven Ansatz werden viele spezielle Ontologien erstellt, die dann miteinander zusammengeführt werden. Der deduktive Ansatz sieht die Festlegung der allgemeinen Konzepte, Regeln und Standards vor, die später spezialisiert werden\autocite{url:ontologieBegriff}.

%Klassifikation: top, domänespezifisch
	Ontologien können zwei Gruppen zugeordnet werden. Zur ersten Gruppe gehören die sogenannten Top-Level-Ontologien, die allgemeine bereichsübergreifende Begriffe enthalten. Die größte formale öffentlich zugängliche Top-Level-Ontologie heutzutage ist Suggested Upper Merged Ontology (SUMO). Sie enthält mehr als 25.000 Konzepte und mehr als 80.000 Axiome\autocite{url:sumo}. Andere weltweite bekannte, große Top-Level-Ontologien sind Dublin Core, GFO, OpenCyc/ResearchCyc und DOLCE. Zur zweiten Gruppe gehören auf bestimmte Anwendungsbereiche bezogene Ontologien, die sogenannten Domäne-Ontologien.

% Wert der Ontologien
	Der Wert einer Ontologie ist von der Größe der Anerkennung in der entsprechenden Fachwelt abhängig. Eine große Anerkennung kann in der Regel dann erreicht werden, wenn möglichst viele Entscheidungsträger und Betroffene am Entwicklungsprozess beteiligt sind, was den Entwicklungsaufwand durch Abstimmungen deutlich erhöht\autocite{url:ontologieBegriff}.

	In den folgenden Abschnitten werden Typen der Ontologien erläutert und ein Überblick über die Ontologiesprache OWL gegeben, auf der das in Kapitel \ref{Konzept der Suche} vorgestellte Konzept der ontologiebasierten Suche basiert.

	\subsection{Typen der Ontologien}
	\label{Typen der Ontologien}
% Unterschiedliche Ontologien
	Man unterscheidet Ontologien je nach ihrer Art, Ausdrucksmächtigkeit und Anwendung. Ein Versuch Typen der Ontologien zu definieren ist die in Abbildung \ref{img:ontology_spectrum} veranschaulichte Klassifizierung von Lassila und McGuinness \autocite{art:ontologyClassification}. Es wird zwischen leichtgewichtigen und schwergewichtigen Ontologien unterschieden. Sie werden in der Abbildung durch eine Linie getrennt.

\begin{figure*}[htbp]
	\centering
		\includegraphics[width=14cm]{figures/an_ontology_spectrum.png}
		\caption{Typen der Ontologien laut Lassila und McGuinness\autocite{art:ontologyClassification}}
		\label{img:ontology_spectrum}
\end{figure*}

	Links auf der Achse befinden sich die einfacheren Ontologietypen wie \emph{Controlled Vocabularies}, \emph{Terms/glossary} und \emph{Thesauri}. Diese Ontologietypen sind wie folgt definiert:
	\begin{itemize}
		\item \emph{Controlled Vocabularies} sind Listen von Begriffen, die Identifikatoren zugeordnet sind. Durch die Verwendung von Identifikatoren kann der Suchaufwand deutlich reduziert werden. Ein Beispiel dazu sind alphabetisch organisierte Listen.
		\item \emph{Terms/glossary} ist wie \emph{Controlled Vocabularies} aufgebaut mit dem Unterschied, dass Begriffe zusätzlich eine Beschreibung haben dürfen.
		\item \emph{Thesauri} sind als eine Sammlung von Begriffen einer Domäne definiert\footnote{\url{http://www.thefreedictionary.com/} (Abruf: 22.11.12)}. \emph{Thesauri} können auch Verknüpfungen zwischen Begriffen und Synonymen enthalten.
		\item \emph{Informal "`is-a"'} ist die erste Stufe der Ontologietypen, die die Zuordnung von Begriffen zu Klassen erlaubt. Dabei geht es um keine ist-ein-Beziehung zwischen Begriffen und Klassen. Begriffe werden nur thematisch gruppiert.
	\end{itemize}
	
	Die beschriebenen Ontologietypen werden oft leichtgewichtige Ontologien (engl. \emph{leightweight ontologies}) genannt, weil sie schwache Ausdrückmächtigkeit haben, z.B. sie erlauben keine Hierarchien. Obwohl sie keine komplexe Beschreibungen erlauben, werden solche Ontologien erfolgreich für die Suche eingesetzt. Eine weltweit verbreitete leichtgewichtige Ontologie ist Dublin Core. Sie hilft Charakteristiken der elektronischen Dokumente durch vordefinierte Eigenschaften (engl. \emph{features}) wie \emph{Besitzer}, \emph{Datum} o.ä. zu spezifizieren\autocite{art:ontologyClassification}.

	Rechts auf der Achse liegen sogenannte schwergewichtige Ontologien (engl. \emph{heavyweight ontologies}). Sie bieten die Möglichkeit Taxonomien, Instanzen und Eigenschaften zu definieren, wodurch eine präzisere Beschreibung einer Domäne erreicht werden kann. Die einzelnen Stufen der schwergewichtigen Ontologien werden wie folgt definiert:
	
\begin{itemize}
	\item Ontologien, die zur Stufe \emph{formal "`is-a"'} gehören, erlauben es, dass Objekte einer Klasse auch zu den Oberklassen dieser Klasse gehören.
	\item Ontologien der Stufe \emph{formal instance} führen den Begriff \emph{Instanz} ein. Die Zuordnung einer Klasse wird als eine ist-ein-Beziehung betrachtet.
	\item \emph{frames (properties)} ist eine Stufe der Ontologien, die die Zuordnung von Eigenschaften Klassen erlauben. Dabei werden die Eigenschaften von Unterklassen geerbt. Falls bei einer Eigenschaft als Wert eine andere Klasse erwartet wird, wird eine solche Eigenschaft \emph{Relation} genannt.
	\item Die Stufe \emph{value restrictions} erlaubt die Einschränkung von Wertebereichen der Eigenschaften. Eine Beschränkung von Datentypen (boolean, Integer u.ä.), Bereichen (engl. \emph{range}) und Klassen (engl. \emph{domain}) ist möglich.
	\item Beim Ontologietyp der Stufe \emph{disjointness, inverse, part-of} können Restriktionen, disjunkte Klassen und inverse Relationen definiert werden. Mithilfe disjunkter Klassen kann verhindert werden, dass Instanzen gleichzeitig zu sich gegenseitig ausschließenden Klassen gehören. Die zweite Einschränkung erlaubt es, dass eine Relation in beide Richtungen von Subjekt zu Objekt und umgekehrt definiert werden kann. Ein Beispiel dazu sind die Relationen \emph{eine Mutter von} und \emph{ein Kind von}.
	\item Mit \emph{general logical constraints} oder Einschränkungen der Prädikatenlogik zwischen Termen können Ontologien maximale Ausdrückfähigkeit erreichen. So können komplexe Einschränkungen (\emph{Axiome}) wie beispielsweise \emph{Existenz einer bestimmten Eigenschaft für Instanzen einer bestimmten Klasse} oder \emph{erlaubte Kombinationen von Eigenschaften für bestimmte Instanzen} festgelegt werden.
\end{itemize}
	\emph{Heavyweight} Ontologien können durch spezielle Software, so genannte Reasoner, auf die Konsistenz geprüft werden. Reasoner können beispielsweise prüfen, ob eine Klasse laut definierten Axiomen überhaupt Individuen haben darf, herausfinden, ob eine Klasse Unterklasse einer anderen Klasse ist sowie prüfen, ob alle definierten Komponenten gegen keine Axiomen verstoßen. Reasoner sind wichtige Werkzeuge, die während der Entwicklung und Erweiterung von Ontologien helfen, eine Ontologie immer in einem konsistenten Zustand zu halten. 

	\subsection{OWL (Web Ontology Language)}
	Ontologien können mithilfe unterschiedlicher Sprachen erstellt werden. Verbreitete Sprachen sind unter anderem DAML+OIL, F-Logic und Resource Description Framework (RDF). Die wohl bekannteste Sprache, die das Bedürfnis nach einer Ontologiesprache für das Netz befriedigen soll und mit der Zeit zu einem einheitlichen Format für Ontologien werden kann, ist OWL (Web Ontology Language). Sie wurde 2004 von W3C-Konsortium spezifiziert und steht in einer Reihe der Empfehlungen für das Semantic Web:
	
\begin{itemize}
	\item \emph{XML} bietet eine Syntax für strukturierte Dokumente. Daten lassen sich mithilfe von Auszeichnungen (Tags) markieren und in Bäume organisieren.

	\item \emph{XML Schema} wird für die Definition der Struktur von XML Dokumenten verwendet und erweitert XML um die Datentypen.

	\item \emph{RDF} ist ein Datenmodell für mittels Relationen verbundene Ressourcen. Durch die Verbindung von Ressourcen entsteht eine Sammlung von Tripeln. Ein solches Tripel besteht aus diesen drei Elementen: Subjekt (Ressource), Prädikat (Relation) und Objekt (Ressource). Das Datenmodell kann in XML repräsentiert werden.

	\item \emph{RDF Schema} stellt ein Vokabular zur Beschreibung der Klassen und Eigenschaften von Ressourcen zur Verfügung. Darüber kann eine Syntax für den gemeinsamen Datenaustausch festgelegt werden.

	\item \emph{OWL} bietet die Möglichkeit Vokabeln zur Beschreibung von Eigenschaften und Klassen hinzuzufügen. Es ist zum Beispiel möglich Mengenoperationen für Klassen, unterschiedliche Kardinalitäten für Eigenschaften, Äquivalenz von Individuen, Einschränkungen von Eigenschaften(z.B. symmetrisch, reflexiv u.a.) und  Eigenschaften unterschiedlicher Typen(\emph{object property} und \emph{data property}) zu definieren.
\end{itemize}

	OWL Ontologien sind XML-Dokumente, die technisch auf der RDF-Syntax basieren und größere Ausdrucksmächtigkeit als RDF Schema haben. Es ist auch wichtig zu unterstreichen, dass OWL kein neues Nachrichtenformat ist, sondern eine Repräsentation von Wissen, die Reasoning außerhalb des Transaktionskonextes ermöglicht\autocite{url:w3cOntology}.

		%TODO ab hier weiter prüfen mit DUDEN
		
		\subsubsection{OWL-Komponenten: Klassen, Individuen, Eigenschaften}		
		\label{OWL-Komponenten: Klassen, Individuen, Eigenschaften}
		In  diesem Abschnitt wird mithilfe von \autocite{art:protegeTutorial} eine kleine Einführung in den Aufbau von OWL gegeben.
		
		OWL-Ontologien bestehen aus drei Komponenten: Klassen, Individuen und Eigenschaften. 
		
		Individuen sind die einfachsten Komponenten. Sie repräsentieren Objekte oder Instanzen einer Domäne. OWL erlaubt eine explizite Definition von mehreren Individuen, die dasselbe Individuum repräsentieren. So können Individuen  \emph{Everest} und \emph{Tschomolangma} als dasselbe Individuum definiert werden.
		
		Klassen in OWL können als Sammlungen von Individuen betrachtet werden. Wenn ein Individuum zu einer Klasse gehört, erfüllt es alle Anforderungen der Klasse. Klassen können hierarchisch organisiert werden. Solche Hierarchien werden \emph{Taxonomien} genannt. Eine Klasse kann durch andere Klassen spezialisiert werden.  Alle Individuen einer Unterklasse gehören automatisch auch zur Oberklasse, da sie deren Anforderungen implizit auch erfüllen. An der Spitze der Klassenhierarchie steht immer Klasse \emph{owl:Thing}. In OWL ist die Mehrfachvererbung von Klassen erlaubt, d.h. eine Unterklasse darf mehr als zwei Oberklassen erweitern. Individuen können gleichzeitig zu mehreren Klassen gehören. Um eine gleichzeitige Zugehörigkeit von Individuen zu bestimmten Klassen auszuschließen, können solche Klassen als disjunkt zueinander definiert werden.
				
		Eigenschaften (engl. \emph{properties}) sind binäre Relationen vom Typ Objekteigenschaft oder Dateneigenschaft.  Objekteigenschaften sind Relationen zwischen zwei Individuen und Dateneigenschaften verbinden ein Individuum mit Datenwerten. 
		
		Objekteigenschaften können genauso wie Klassen in Taxonomien organisiert werden. Für eine Objekteigenschaft kann explizit eine inverse Eigenschaft definiert werden, z.B. für Objekteigenschaften \emph{ist Hauptstadt von} kann eine inverse Eigenschaft \emph{hat Hauptstadt} definiert werden. Für Objekteigenschafte können auch einige Charakteristika festgelegt werden: Transitivität, Funktionalität, inverse Funktionalität, Symmetrie, Asymmetrie, Reflexivität und Irreflexivität. Genauso wie bei Klassen können Objekteigenschaften als disjunkt definiert werden. Außerdem ist es möglich die Zugehörigkeit von Individuen einer Objekteigenschaften zu bestimmten Klassen einzuschränken.
		
		Dateneigenschaften verbinden ein Individuum mit typisierten und nicht typisierten Datenwerten. Datentypen können entweder von XML-Schema-Datentypen entstammen oder RDF-Literale sein\autocite{url:w3cOntology}. Im Unterschied zu Objekteigenschaften können Dateneigenschaften nur ein einziges Charakteristikum \emph{Funktionalität} haben. Ein Individuum kann nur eine funktionale Dateneigenschaft haben. Dateneigenschaften können auch so definiert werden, dass nur Individuen bestimmter Klassen sie haben dürfen.
		
		Mithilfe der drei vorgestellten Komponenten können komplexe Domäne beschrieben werden.
		
		\subsubsection{OWL-Untersprachen}
		\label{OWL-Untersprachen}
		OWL hat drei Untersprachen. Sie werden im Folgenden laut \autocite{url:w3cOntology} in der Reihenfolge steigender Ausdrucksstärke beschrieben:
\begin{itemize}

	\item \emph{OWL Lite} unterstützt Klassifikationshierarchien und einfache Restriktionen wie  Kardinalitätsrestriktionen mit den Werten 0 und 1. Die Entwicklung von Anwendungen für OWL Lite ist im Vergleich zu anderen OWL-Untersprachen durch die geringere formale Komplexität einfacher, aber wenn eine Ontologie disjunkte Klassen, flexible Kardinalitätsdefinitionen oder Mengenoperationen enthalten soll, ist \emph{OWL Lite} nicht ausreichend. 
	
	\item  \emph{OWL DL} unterstützt maximale Ausdrucksstärke und vollständige Verarbeitbarkeit, d.h. alle Schlüsse können gezogen werden. Außerdem wird bei \emph{OWL DL} jede Verarbeitung in endlicher Zeit durchgeführt. \emph{OWL DL} hat alle OWL Sprachkonstrukte, aber ihre Verwendung wird eingeschränkt. So kann eine Klasse von anderen Klassen erben, aber sie kann nicht als eine Instanz einer anderen Klasse definiert werden. Die Mengen von Objekt- und Dateneigenschaften sind in \emph{OWL DL} disjunkt. Die Kardinalität von transitiven Eigenschaften kann nicht definiert werden. Es gibt auch andere Einschränkungen.
	
	\emph{OWL DL} wird so genannt, weil sie Anforderungen von beschreibender Logik\footnote{Beschreibender Logik ist eine Untermenge von Prädikatenlogik erster Stufe.} (engl.\emph{description logic}) genügt\autocite{url:w3cOntology}. 

	\item \emph{OWL Full} bietet maximale Ausdrucksstärke und die syntaktische Freiheit von RDF. Die Verarbeitbarkeit von \emph{OWL-Full}-Dokumenten wird nicht garantiert. Eine Klasse kann als ein Individuum und als eine Sammlung von Individuen definiert werden. \emph{OWL Full} erlaubt es, einer Ontologie die Bedeutung von vordefiniertem RDF- oder OWL-Vokabular zu erweitern. Es ist unwahrscheinlich, das komplette Schlussfolgern für jedes Feature einer OWL-Full-Ontologie zu unterstützen.
\end{itemize}

Die Wahl der Untersprache hängt davon ab, für welche Zwecke Ontologien erstellt werden. Der Unterschied zwischen OWL Lite und OWL DL besteht vor allem in ihrer Ausdruckskraft. Bei der Wahl zwischen OWL DL und OWL Full wird entschieden, ob Meta-Modelling-Möglichkeiten von RDF Schema wie beispielsweise Klassen von Klassen-Definitionen oder Zuweisungen von Eigenschaften bestimmte Klassen voraussetzen. OWL Full bietet zwar diese Möglichkeit im Unterschied zu OWL DL, aber sie kann schlechter durch  Schlussfolgerungssoftware unterstützt werden, denn es gibt noch keine OWL Full Implementierungen\autocite{url:w3cOntology}.

\newpage	
\section{Verwandte Arbeiten}
\label{Verwandte Arbeiten}
	Die Idee, Semantik bei der Suche nach Dateien zu berücksichtigen, ist nicht neu. Es gibt viele Arbeiten, die unterschiedliche Ansätze und Ideen in diesem Bereich und verwandten Bereichen beschreiben. Im Folgenden werden einige von ihnen vorgestellt und diskutiert.
	 
	In der Einleitung zu dieser Arbeit wurde das in \autocite{art:semanticFileSystemSIL} präsentierte semantische Dateisystem SIL diskutiert. Wie der Name des Dateisystems schon ausdrückt, werden Dateien innerhalb von SIL aus der Sicht des Benutzers nicht durch herkömmliche Dateipfade angesprochen, sondern durch die Beschreibung ihrer Inhalte "`lokalisiert"', d.h. für den Zugriff auf Dateien werden ihre Beschreibungen eingesetzt. Die Beschreibung von Dateieninhalten ist in SIL mithilfe von Tags realisiert. Die Tags ermöglichen zwar die Suche nach Dateien mit gewünschtem Inhalt, die Semantik der Tags wird dabei jedoch nicht berücksichtigt. Die vorliegende Arbeit soll eine allgemeine Lösung bieten, die durch die Verwendung von Ontologien die Suche nach Dateien semantisch macht. Somit kann \autocite{art:semanticFileSystemSIL} als Ausgangspunkt oder Quelle der Aufgabestellung betrachtet werden.
	
	%Auf Basis der Ideen aus \autocite{art:semanticFileSystemSIL} wurde im Rahmen eines Teamprojekts an der HTWG Konstanz Dateisystem FS32 realisiert, die in \autocite{art:fs32} beschrieben wurde.
		
	Ein interessanter Ansatz für semantische Suche nach Dateien wird in
	\autocite{art:OntBasedPhotoAnnotation} präsentiert. Der Artikel beschäftigt sich mit der Frage, wie man durch die Anwendung von Ontologien große Bilder-Sammlungen domänenspezifisch annotieren kann. A. Th. (Guus) Schreiber und Kollegen beschreiben eine Vorgehensweise, bei der zuerst eine domänenspezifische Ontologie vom Benutzer angelegt wird. Diese Ontologie wird bei der Generierung einer GUI-Anwendung verwendet, die für das Annotieren der Bilder-Sammlung eingesetzt wird. Gleichzeitig wird ein ontologiebasiertes Tool für die Suche nach Bildern generiert. Der Benutzer des Tools wird bei der Formulierung der Anfragen durch Formulare eingeschränkt. Nur Anfragen, die für die benutzte Ontologie relevant sind, werden vom System akzeptiert. Der Benutzer ist in seiner Wahl zwar eingeschränkt, aber so können sehr präzise Suchergebnisse erreicht werden. Die vorgeschlagene Vorgehensweise ist nur teilweise automatisiert und erfordert ein gutes Wissen über die Domäne und die Ontologien. Außerdem soll das Annotieren der Dateien manuell erfolgen. Aus diesen Gründen ist der Ansatz zum Beispiel für die Suche in großen wissenschaftlichen Sammlungen von Multimediadateien geeignet. Bei solchen Sammlungen spielt die Präzision der Suchergebnisse eine große Rolle und der Inhalt der Dateien muss sehr genau und domänenspezifisch beschrieben werden.

	Die Autoren von \autocite{art:OntBasedInterpOfKeyWords} präsentieren einen Ansatz zur Interpretation der Suchanfragen mithilfe von Ontologien. Unter Berücksichtigung einiger Annahmen darüber, wie Benutzer ihre Suchwünsche beschreiben, werden die Suchanfragen in Form von Stichwörtern interpretiert und in eine interne Anfragesprache übersetzt. Die übersetzten Anfragen werden dann auf die Ontologie angewendet, um zusätzliche Muster für die Suche zu finden oder unnötige Suchergebnisse zu vermeiden. Im Artikel wird auf den theoretischen Aspekt der semantischen Suche eingegangen und mithilfe eines Modells bestehend aus vier Elementen beschrieben: 
	\begin{itemize}
		\item Das Element \emph{Mental-Modell} enthält die miteinander assoziierten und für die
		Suche relevanten Entitäten in Gedanken des Benutzers. Diese Entitäten repräsentieren das,
		was der 	Benutzer weiß. Bei der Suche fehlen dem Benutzer einige Entitäten in der von ihm
		konstruierten Struktur. Die Autoren nehmen an, dass die fehlenden Entitäten eine Suche
		verursachen und nennen solche Entitäten \emph{Gaps}.
		
		\item Das nächste Element, das \emph{Fragemodell des Benutzers}, besteht aus Primitiven
		einer natürlichen Sprache. Die Entities des Mental-Modells werden vom Benutzer in
		Primitive einer natürlichen Sprache übersetzt.
		
		\item Das Element \emph{System-Ressourcen-Modell} enthält eine Sammlung von Entitäten
		einer gegebenen Ontologie.
		
		\item Das letzte Element, das \emph{System-Anfrage-Modell}, besteht aus Primitiven der
		Anfrage-Sprache	und 	repräsentiert die Anfrage, die von einer Suchkomponente bearbeitet
		wird.
	\end{itemize}
	Dieses Modell wird in \ref{Formale Anfragesprache statt Stichwörter} dazu verwendet, alternative Anfrageformen an ein ontologiebasiertes Suchsystem zu diskutieren und anschließend eine davon auszuwählen.

%TODO ab hier weiter prüfen mit DUDEN	
\newpage	
\section{Konzept ontologiebasierter Dateisuche}
\label{Konzept der Suche}
	Das vorliegende Konzept beschreibt ein ontologiebasiertes Suchsystem für Dateien, das die Vorteile von Ontologien so nutzt, dass qualitativ hohe Suchergebnisse für präzise aber auch für unscharfe Suchen erreicht werden. 
	
	Wie auch bei anderen Systemen, ist bei einem Suchsystem das Zusammenspiel der einzelnen Komponenten entscheidend für die Effiktivität des Gesamtsystems. Aus diesem Grund besteht die Grundidee des Konzepts darin die Interaktion zwischen den Elementen möglichst eindeutig zu machen. Die Elemente eines ontologiebasierten Suchsystems für Dateien sind:
	\begin{itemize}
	\item eine Ontologie, die Informationen über eine Domäne enthält,
	\item eine Anfragesprache, die vom Benutzer formuliert und vom System interpretiert wird und
	\item Inhaltsbeschreibungen von Dateien.	
	\end{itemize}
Anfragen des Benutzers und Inhaltsbeschreibungen der Dateien dürfen nur Begriffe einer oder mehreren Ontologien verwenden.  Dadurch sollen die maschinelle Verarbeitung und die Qualität der Suchergebnisse verbessert werden.
	Neben den drei erwähnten Elementen müssen noch drei Elemente vorgestellt werden, die gleichzeitig funktionale Komponenten des Systems sind:
	\begin{itemize}
	\item eine Suchkomponente, die die Anfragen des Benutzers interpretiert und mithilfe einer Ontologie genaue oder unscharfe Ergebnisse zurückliefert,
	\item ein Editor für ontologiebasierte Inhaltsbeschreibungen und
	\item eine zusätzliche Komponente, die die automatische Extraktion der vorhandenen standardisierten Inhaltsbeschreibungen von Dateien ermöglicht. Diese Komponente soll eine ergänzende Rolle spielen und dient der Effizienzsteigerung des Systems.
	\end{itemize}
	
	Zu den Elementen des Systems gehören auch der Benutzer, eine Sammlung von Dateien und vorhandene standardisierte Inhaltsbeschreibungen der Dateien. Der Benutzer kann Anfragen an das Suchsystem formulieren, Inhalte der Dateien mithilfe einer Ontologie beschreiben und vorhandene standardisierte Inhaltsbeschreibungen mithilfe einer Ontologie automatisiert extrahieren, um diese in den ontologiebasierten Kontext des Systems zu integrieren. 
	
	Nachdem alle Elemente des Suchsystems definiert sind, sollen die einzelnen Fragen zu Interaktionen zwischen den Elementen und ihren Funktionsweisen beantwortet werden. Die Antworten auf die Fragen, Lösungen einzelner Probleme und Beschreibungen der Alternativlösungen werden in einzelnen Abschnitten dieses Kapitels vorgestellt. Im letzten Abschnitt dieses Kapitels wird ein Überblick über das Konzept gegeben und das Konzept als Ganzes in Detail veranschaulicht.
	
	Die Elemente des Suchsystems werden in Abbildung \ref{img:KonzeptUeberblick} gezeigt. Neben den Elementen stehen für das Konzept relevante Fragen, die in den einzelnen Abschnitten des Kapitels beantwortet werden.
	
	\begin{figure*}[htbp]
	\centering
	\includegraphics[width=12cm]{figures/ueberblickKonzept.pdf}
	\caption{Überblick über Elemente eines ontologiebasierten Suchsystems und Fragen zu den einzelnen Abschnitten des Kapitels \ref{Konzept der Suche}}
	\label{img:KonzeptUeberblick}
\end{figure*}
	

\subsection{Auswahl der Ontologiesprache}
\label{Auswahl der Ontologiesprache}

	Als Ontologiesprache für das Konzept wurde OWl ausgewählt, denn diese Ontologiesprache hat zwei wichtige Eigenschaften:
	\begin{itemize}
	\item OWL ist eine Empfehlung von W3C-Konsortiums, ist weit verbreitet und gewinnt immer mehr an Bedeutung,
	\item Mithilfe von OWL können die sogenannten schwergewichtige Ontologien erstellt werden, die beliebig komplexe Beschreibungen der Domäne erlauben (s. mehr dazu in Abschnitt \ref{Typen der Ontologien}). Besonders wichtig für das Suchsystem sind die Stufen der Ausdrucksmächtigkeit \emph{Formal "`is-a"'} und \emph{Formal Instance} nach Klassifizierung von Lassila und McGuinness in \autocite{art:ontologyClassification}. 
	\end{itemize}
	
	In Abschnitt \ref{OWL-Untersprachen} (OWL-Untersprachen) wurden drei Untersprachen von OWL vorgestellt: OWL Light, OWL DL und OWL Full. Ontologien jeder dieser Untersprachen können in das Suchsystem eingebunden werden, denn sie erfüllen die für die Suchkomponente notwendige Bedingungen. Für das Suchsystem ist die Untersprache irrelevant, weil es nur Grundeigenschaften wie Unterstützung von Taxonomien für Individuen und Eigenschaften oder Zugehörigkeit eines Individuums zu allen Oberklassen einer Klasse nutzt. Diese Eigenschaften sind in allen drei Untersprachen vorhanden.
	
\subsection{Ontologiebasierte Metadaten}
\label{Ontologiebasierte Metadaten}

	Jede Datei, die durch ontologiebasierte Suche potenziell gefunden werden kann, muss zwei Bedingungen erfüllen: sie muss ihren Inhalt in irgendeiner Form beschreiben und diese Beschreibung muss Begriffe einer Ontologie verwenden. 
	
	Die Information darüber, welchen Inhalt eine Datei hat, sogenannte Metadaten der Datei, können im Dateipfad ausgedrückt werden. In dem Fall kann einfache musterbasierte Suche in den Dateipfaden eingesetzt werden. Dieser Ansatz scheint zwar auf den ersten Blick sinnvoll zu sein, aber das führt zu einigen Problemen:			
			\begin{itemize}		
				\item Es können Situationen entstehen, die den Benutzer zwingen, eine Datei \emph{mehreren} Verzeichnissen zuzuordnen. In dem Fall können Links angelegt oder gleiche Dateien mehrmals gespeichert werden. Allerdings führen die redundant gespeicherten Daten auch in Form von Links zu gewissen Problemen.
				\item Da Metadaten Begriffe der Ontologien nutzen müssen, sind auch Verzeichnisse und Dateien mit Begriffen der Ontologien zu benennen. Wenn eine Sammlung vor der Erstellung einer Ontologie existiert hat, dann muss eine Ontologie die Namen der Verzeichnisse als Namen für eigene Elemente verwenden. Anderenfalls müssen Verzeichnisse und Dateien entsprechend umbenannt werden. 
				\item Wenn für eine Datei sehr viele Metadaten gespeichert werden müssen, führt das dazu, dass sehr komplizierte Verzeichnishierarchien erstellt und gepflegt werden müssen, so dass im Dateipfad alle entsprechenden Elemente der Ontologie als Namen der Verzeichnisse vorkommen. Noch eine Konsequenz wäre das bereits beschriebene Problem der Zuordnung von Dateien zu mehreren Verzeichnissen.					
			\end{itemize}
	Aufgrund der erwähnten Probleme, ist die Verwendung von Pfaden als Ersatz für explizit definierte Metadaten für das Konzept ungeeignet.
	
	Der andere Ansatz sieht die Verwendung von Metadaten vor. Dabei können Metadaten in der Datei selbst, in einer Datenbank oder in einer anderen assoziierten Datei gespeichert werden. Diese Alternativen haben ihre Vor- und Nachteile:

 \begin{itemize}
 	\item Die Speicherung von Metadaten in speziellen Bereichen der Dateien hat einen großen Nachteil, dass nicht alle Dateitypen die entsprechende Möglichkeit bieten. Außerdem muss die Speicherung von ontologiebasierten Tags im Rahmen der Metadatastandards korrekt sein, d.h. ontologiebasierte Tags müssen valide und semantisch passend zu den Feldern oder Eigenschaften dieser Standards sein. Das kann nicht für alle Dateitypen garantiert werden. Somit wäre eine  ontologiebasierte Suche für viele Datentypen nicht möglich oder problematisch. Ein weiterer Nachteil besteht darin, dass eine Suchanwendung Zugriff auf die Metadaten bekommen muss und die Implementierung des Zugriffs unterschiedlicher Dateitypen unterschiedlich sein wird. Es ist sehr wahrscheinlich, dass von einer Suchanwendung nicht alle Dateitypen bearbeitet werden können.
 	\item Die Speicherung von Metadaten in einer Datenbank ist aus Performance-Gründen eine gute Lösung. Außerdem werden Metadaten zentral gehalten und können mithilfe von DML-Befehlen\footnote{ \emph{Data Manipulation Language(DML)} ist ein Teil einer Datenbanksprache, der das Lesen, Schreiben, Ändern und Löschen von Daten ermöglicht.} bearbeitet werden. Die Nachteile sind die aufwendige Migration von Metadaten und die Notwendigkeit automatisierter Pflege der Informationen über Dateipfade.
 	\item Die letzte Alternative, die Speicherung der Metadaten in zusätzlichen Dateien, hat den Vorteil, dass die Migration einfach ist. Dateien können zusammen mit Metadatendateien von einem System in ein anderes System übertragen werden. Außerdem wird keine automatisierte Verwaltung von Informationen über Dateipfade benötigt, wenn Namen von Metadatendateien durch bestimmte Regeln abhängig von den Dateinamen gemacht werden und wenn Metadatendateien im selben Verzeichnis zusammen mit beschriebenen Dateien gespeichert werden. Der Nachteil dieser Alternative ist die Verdoppelung der Anzahl von Dateien.
 \end{itemize}
	
	Trotz des Nachteils bezüglich der Dateianzahl fiel die Entscheidung im Rahmen dieser Arbeit auf die dritte Alternative, weil sie einfachere Migration von Metadaten zusammen mit den Daten ermöglicht und Flexibilität bei der Definition der Metadaten-Struktur bietet.
	
	Metadatendateien können entweder in einem für Menschen lesbaren Format mit vordefinierter Struktur (z.B. XML) oder in einem proprietären Format gespeichert werden. Die erste Variante bietet zwar Flexibilität bei der Bearbeitung der Metadatendateien, aber sie erfordert auch ständiges Parsen bei Lesezugriffen während der Suche, was sich bei großen Dateimengen negativ auf die Performance auswirken kann. Aus diesem Grund wäre ein eigener Dateityp für Metadaten erforderlich. Das Konzept sieht die Verwendung von speziellen Editoren für Zugriff auf die ontologiebasierte Metadaten in Dateien dieses Dateityps vor.

	Für jede beschriebene Datei wird im selben Verzeichnis eine Metadatendatei mit der Erweiterung \emph{.ose}\footnote{\emph{OSE} als Abkürzung für \emph{Ontology based Search Engine}} angelegt. Durch eine einfache Namenskonvention ist eine eindeutige Zuordnung der Metadatendateien entsprechenden Dateien möglich. Der Name einer .ose-Datei fängt mit dem Namen der beschreibenden Datei, anschließend folgt Unterstrich, Erweiterung der beschreibenden Datei und schließlich Erweiterung \emph{.ose}. So wird zum Beispiel für eine Datei mit dem Namen \emph{Bericht.pdf} eine Metadatendatei mit dem Namen \emph{Bericht\_pdf.ose} im selben Verzeichnis angelegt.

	Metadaten einer Datei werden als eine Sammlung von Tags organisiert \footnote{Die Idee Tags für die Beschreibung der Dateiinhalte zu verwenden stammt aus \autocite{art:semanticFileSystemSIL}}. Elemente der eingebundenen Ontologie werden bei der Beschreibung einer Datei zu Metadatentags, die vom Benutzer aktiviert und deaktiviert werden können. Das führt zu zwei positiven Effekten. Erstens werden nur ontologiebasierte Tags bei der Inhaltsbeschreibung verwendet und der Benutzer ist gezwungen die Ontologie zu erweitern, wenn bestimmte Dateiinhalte nicht ausgedrückt werden können. Zweitens werden nur Tags der eingebundenen Ontologie bei der Suche berücksichtigt, wodurch unnötige Vergleiche während der Suche vermieden werden, was die Performance wesentlich verbessern soll.

	Die Menge von Tags entspricht der Menge von Klassen und Individuen einer OWL-Ontologie. Jedes Tag hat zwei Zustände: es kann aktiviert oder deaktiviert sein. Die Auswahl von Tags, die für eine Datei aktiviert werden müssen erfolgt nach folgendem Prinzip: passt ein Individuum-Tag für die Beschreibung des Inhalts, wird es aktiviert. Falls kein passendes Individuum-Tag gefunden wird, kann das entsprechende Klassen-Tag aktiviert werden, sonst muss die Ontologie um ein Individuum erweitert werden.

	Da eine Datei mithilfe von mehreren Ontologien beschrieben werden kann, muss jedes Metadatenelement Information darüber enthalten, zu welcher Ontologie es gehört. Das hilft bei der Bearbeitung von Metadaten die Domänen einzelner Elemente zu unterscheiden und Namenskonflikte zu vermeiden.

	Wenn eine Datei mithilfe einer Ontologie beschrieben wird, die früher für die Beschreibung dieser Datei nicht verwendet wurde, dann werden alle Individuen- und Klassentags der neuen Ontologie automatisch in der Metadatendatei angelegt und deaktiviert. Sie können nur manuell oder mithilfe der Extraktionskomponente aktiviert werden.

Ontologiebasierte Tags haben folgende Syntax: 
	\begin{lstlisting}
<Name der OWL-Datei ohne .owl Erweiterung>/[CL|IN]_<Name des Tags>
	\end{lstlisting}
Der erste Teil eines Tags verbindet das Tag mit einer Ontologie. Die Abkürzungen CL und IN stehen für \emph{Class} und \emph{Individual} und geben Typ des Tags an. Nach dem Typ und einem Unterstrich folgt Name des Tags. Der Name ist der URI-Fragmentbezeichner des Ontologieelements in OWL, wie zum Beispiel \emph{Serbien} aus folgendem URI:
	\begin{lstlisting}
http://www.example.org/ontologies/2012/example.owl#Serbien
	\end{lstlisting}

	Die Verbindung von ontologiebasierten Metadaten mit Elementen einer Ontologie wird anhand eines einfachen Beispiels in Abildung \ref{img:metadatenUndElementeOWL} veranschaulicht.

\begin{figure*}[htbp]
	\centering
	\includegraphics[width=14cm]{figures/metadatenBeispiel.pdf}
	\caption{Ontologiebasierte Metadaten und Elemente der OWL}
	\label{img:metadatenUndElementeOWL}
\end{figure*}

\subsection{Vorgehensweise bei der Beschreibung der Dateien}
\label{Vorgehensweise bei der Beschreibung der Dateien}

	Die Vorgehensweise des Benutzers bei der Beschreibung der Dateien wird im Folgenden anhand eines  Beispiels gezeigt.

	Angenommen, ein Benutzer hat eine thematische Sammlung von Fotos, die er für die ontologiebasierte Suche adaptieren will. Als erstes wird eine Ontologie benötigt, die die Domäne der Sammlung beschreibt. Eine Ontologie kann mithilfe eines Editors in folgenden Schritten erstellt werden:

\begin{enumerate}
	\item Der Benutzer fängt mit der Definition der allgemeinsten Klassen an. Dann werden die Klassen durch Unterklassen erweitert.
	\item Im nächsten Schritt werden die meisten Individuen der Klassen definiert.
	\item Anschließend werden allgemeine Eigenschaften und danach speziellere oder erbende Eigenschaften definiert.
	\item Schließlich können Individuen durch Eigenschaften miteinander verbunden werden.
\end{enumerate}

	Die erstellte Ontologie muss die Domäne nicht unbedingt vollständig beschreiben. Sie kann während der Beschreibung von Dateien an die Bedürfnisse des Benutzers angepasst werden.

	Nachdem eine Ontologie erstellt wurde, können Dateien mit ihrer Hilfe beschrieben werden. Bei der Beschreibung, die in einem speziellen Tool erfolgt, werden für jede Datei Tags aktiviert, die Individuen und Klassen der erstellten Ontologie repräsentieren. Zuerst wird versucht passende Tags zu finden, die Individuen repräsentieren. Wenn kein passendes Tag gefunden wird, können Klassentags aktiviert werden. Anderenfalls muss wie bereits beschrieben Ontologie um ein neues Individuen mit passenden Eigenschaften erweitert werden. Im Laufe der Beschreibung wird die vorher erstellte Ontologie manuell erweitert und gleichzeitig werden die Metadatendateien automatisch mit neuen Tags versorgt. Falls eine Datei Metadaten von mehreren Ontologien enthält, werden sie in derselben Datei gespeichert. 
	
	Wenn eine Ontologie geändert wird, werden die Elemente der Metadaten beim Öffnen der Dateien im Metadaten-Editor mit den aktuellen Elementen der Ontologie zusammengeführt. Alle aus der Ontologie entfernten Elemente werden auch aus Metadaten entfernt und alle neuen Elemente werden hinzugefügt.

	Die Metadaten werden in Dateien gespeichert, die nur vom Beschreibungstool geöffnet werden können. Im Idealfall ist die Anzahl der beschriebenen Dateien gleich der Anzahl an Metadaten-Dateien. Die Dateien, die nicht beschrieben wurden, werden später bei der ontologiebasierten Suche ignoriert.

	Nachdem die Dateien beschrieben wurden, kann der Benutzer in einer speziell dafür entwickelten Anwendung ontologiebasierte Anfragen stellen und die Ergebnisse betrachten.

\subsection{Bearbeitung der Suchanfragen und die ontologiebasierte Anfragesprache}
\label{Ontologiebasierte Anfragesprache}

	Dieser Abschnitt beschäftigt sich mit der Hauptfunktion eines ontologiebasierten Suchsystems, also mit der Suchfunktion. Am Anfang des Abschnitts wird ein kurzer Überblick über den Suchvorgang gegeben, um ihn in den nachfolgenden Abschnitten detaillierter zu erläutern. Zuerst wird die Entscheidung zugunsten einer formalen Anfragesprache begründet. Anschließend werden Arten des Suchverhaltens erläutert und die Anwendung der Ontologien für die einzelne Sucharten vorgeschlagen. Zum Schluss des Abschnitts wird die Anfragesprache \emph{DOQL} (Dynamic Ontology based Query Language) vorgestellt, die zusammen mit den ontologiebasierten Metadaten zu den Hauptideen des Konzeptes gehört.

\subsubsection{Bearbeitung der Suchanfragen}
\label{Bearbeitung der Suchanfragen}

	In diesem Abschnitt wird der Suchvorgang vom Empfang einer Anfrage und bis zur Ausgabe der gefundenen Dateien erläutert. 

	Die Bearbeitung der Suchanfragen besteht aus zwei Schritten: 
	\begin{enumerate}
	\item Im ersten Schritt wird die Anfrage des Benutzers mithilfe einer eingebundenen Ontologie in einen Satz ontologiebasierter Tags umgewandelt. Diese Tags repräsentieren eine Teilmenge aller Individuen und Klassen der eingebundenen Ontologie. Die Transformation der Anfragen in ontologiebasierte Tags ist notwendig, weil Dateien ausschließlich mithilfe  von solchen Tags beschrieben werden. In diesem Schritt werden auch zusätzliche, semantisch passende Tags aus der eingebundenen Ontologie extrahiert und zu den Tags, die das Ergebnis der Umwandlung der Anfrage sind, hinzugefügt. Die Gesamtmenge der im ersten Schritt gewonnenen Tags enthält mehr Informationen für die Suche, als vom Benutzer mithilfe der Anfrage angegeben wurde.
	
	Welche Form Benutzeranfragen haben, wie sie vom Suchsystem interpretiert werden und wie  zusätzliche Tags aus einer eingebundenen Ontologie extrahiert werden, wird in nachfolgenden Abschnitten ausführlich erläutert.
	\item Im zweiten Schritt werden die ontologiebasierte Metadaten der Dateien mithilfe der Tags aus dem ersten Schritt untersucht. Es wird dabei nach Dateien gesucht, die in ihren Metadaten \emph{aktivierte} Tags aus der Menge der im ersten Schritt gewonnenen Tags haben. Alle Dateien die dieses Kriterium erfüllen, werden vom System als Ergebnis zurückgeliefert.
	\end{enumerate}

	Die oben beschriebenen Schritte können anhand eines einfachen Beispiels erläutert werden. Nehmen wir an, der Benutzer will eine Datei finden, die Informationen über Gebäude beinhaltet. Er formuliert eine Anfrage, die in irgendeiner Form das Wort \emph{Gebäude} enthält. Das Suchsystem transformiert die Anfrage in ein Tag mit dem Wort \emph{Gebäude}. Anschließend werden zusätzliche semantische Tags aus der eingebundenen Ontologie extrahiert. Die Suchkomponente des Systems kann beispielsweise zusätzliche Individuentags mit den Namen \emph{Dom}, \emph{Fabrik} o.ä. bilden und diese Tags auch im zweiten Schritt des Suchvorgangs benutzen. Im zweiten Schritt werden die gefundenen Tags mit den Namen \emph{Gebäude}, \emph{Dom} und \emph{Fabrik} in Metadaten der Dateien gesucht. Bei einem Treffer wird geprüft, ob entsprechendes Tag aktiviert ist. Wenn das der Fall ist, dann wird die Datei zur Liste der gefundenen Dateien hinzugefügt. Für einen Treffer ist es ausreichend, wenn bereits ein passendes Tag in den Metadaten der Datei aktiviert wird.

	\subsubsection{Formale Anfragesprache statt Stichwörter}
	\label{Formale Anfragesprache statt Stichwörter}

	Bevor die Anfragesprache des Suchsystems beschrieben wird, soll die Entscheidung begründet werden, eine formale Anfragesprache statt Anfragen in Form von Stichwörtern zu benutzen. Dafür muss der Kommunikationsprozess zwischen einem Benutzer und einem ontologiebasierten Suchsystem betrachtet werden. Für die Begründung wird das Kommunikationsmodell aus \autocite{art:OntBasedInterpOfKeyWords} verwendet. 
	In diesem Modell definieren Tran und Kollegen vier Elemente: 
	\begin{itemize}
		\item nicht-formulierte Vorstellungen darüber, was der Benutzer sucht,
		\item Vorstellungen, die vom Benutzer in Form von	Stichwörtern einer natürlichen Sprache
		formuliert werden,
		\item ein \emph{Ressourcen-Modell} des Suchsystems in Form einer Ontologie und
		\item ein \emph{Anfrage-Modell} des Suchsystems oder eine formale Anfragesprache, die vom
		System akzeptiert wird. Ein System kann auch Anfragen in Form von Stichwörtern akzeptieren und			interpretieren.
	\end{itemize}
	
	 Der Ablauf der Suche entsprechend diesem Modell besteht aus vier Phasen. Am Anfang entsteht bei einem Benutzer ein nicht-formulierter Wunsch eine bestimmte Ressource zu finden. Dann wird dieser Suchwunsch vom Benutzer in natürlicher Sprache für sich selbst formuliert. Danach wird die in natürlicher Sprache formulierte Anfrage vom Benutzer entweder in eine Anfragesprache des Systems übersetzt oder als eine Reihe von Tags angegeben, die vom System in Anfragesprache übersetzt werden. Anschließend wird die Anfrage mithilfe des \emph{Ressourcen-Modells} vom System bearbeitet und das Ergebnis wird zurückgeliefert. Das Modell ist in Abbildung \ref{img:Kommunikationsmodell} veranschaulicht.
	 
	 % bylo zdes 4
	
	
	Aus dem beschriebenen Modell folgt, dass die Kommunikation zwischen einem Suchsystem und einem Benutzer erst dann möglich ist, wenn entweder der Benutzer die Anfragesprache des Systems erlernt, oder das System die in Stichwörtern formulierten Anfragen in eigene Anfragesprache übersetzen kann. Beide Varianten haben Vor- und Nachteile, die für das Konzept von großer Bedeutung sind:
	
	% Alternative 1: Benutzer lernt Anfragesprache
	\begin{enumerate}
	\item Die erste Variante, die Verwendung der Anfragesprache des Systems, hat den großen Vorteil, dass das System die Suchanfrage eindeutig interpretieren kann und die Übersetzung in die Anfragesprache entfällt. Dadurch, dass der Benutzer ohne unnötige Interpretation seine Suchwünsche mithilfe einer ontologiebasierten Anfragesprache formuliert, können alle Vorteile, die Ontologien bieten, besser ausgenutzt werden. Der Nachteil ist der Aufwand für das Erlernen der Anfragesprache des Systems. Dieser Nachteil wurde z.B. in \autocite{art:OntBasedPhotoAnnotation} umgegangen, indem ontologiebasierte Formulare mit eingeschränkten Auswahlmöglichkeiten für die Formulierung der Anfragen generiert wurden. Durch die Verwendung einer ontologiebasierten Anfragesprache hängt die Präzision von Ergebnissen vor allem davon ab, wie gut der Benutzer seine Suchwünsche in der Anfragesprache formuliert und wie gut die ausgewählte Ontologie ihre Domäne beschreibt. Die Verwendung einer ontologiebasierten Anfragesprache führt auch dazu, dass der Benutzer ein Suchsystem nicht wie eine Blackbox betrachtet, sondern in der Lage ist, die Stärken und Grenzen des Systems zu erkennen.
	
	Die erste Variante wird in Abbildung \ref{img:KommunikationsmodellKonzept} veranschaulicht.	

	
	% Alternative 2: System versucht herauszufinden, was der Benutzer meint	
	\item Die zweite Variante hat für den Benutzer den Vorteil, dass Anfragen leichter formuliert werden können. So erlauben Internet-Suchmaschinen üblicherweise die Eingabe einer Reihe von in natürlicher Sprache formulierter Tags. Der Nachteil von solchen Anfragen ist die nicht-eindeutige Interpretation durch das Suchsystem. Der Nachteil von solchen Anfragen ist nicht eindeutige Interpretation vom Suchsystem. Ein Beispiel dazu ist das Problem von sogenannten \emph{Gaps}, das in \autocite{art:OntBasedInterpOfKeyWords} beschrieben wurde. \emph{Gaps} sind nicht-explizit formulierte Beziehungen zwischen mehr als zwei in der Anfrage angegebenen Begriffen, die anhand der vorhandenen Ontologie zu interpretieren sind. Solche unklaren Beziehungen können durch spezielle Ontologieanalyse mit immer unterschiedlicher Wahrscheinlichkeit erfolgreich rekonstruiert werden. Ein weiteres Problem ist die schwache Mächtigkeit der Suchanfragen, die dazu führt, dass Vorteile von Ontologien, wie z.B. Klassifizierung der Domäne, Vererbung, Beziehungen zwischen Individuen, nur ein wenig oder gar nicht verwendet werden können. Wenn ein System sehr präzise Suchergebnisse liefern muss, ist diese Alternative nicht geeignet. Sie kann aber beschränkt für die unscharfe Suche verwendet werden, wo Präzision der Suchergebnisse nicht wichtig ist.
	
	Zur Veranschaulichung der zweiten Variante dient das Kommunikationsmodell der Abbildung \ref{img:Kommunikationsmodell}
	\end{enumerate}	
	
	\begin{figure*}[htbp]
		\centering
		\includegraphics[width=12cm]{figures/kommunikationsmodellKonzept.pdf}
		\caption{Kommunikation zwischen Benutzer und einem ontologiebasierten Suchsystem
		durch die Verwendung der Anfragesprache des Suchsystems}
		\label{img:KommunikationsmodellKonzept}
	\end{figure*}
	
	\begin{figure*}[htbp]
		\centering
		\includegraphics[width=12cm]{figures/kommunikationsmodell.pdf}
		\caption{Kommunikation zwischen Benutzer und einem ontologiebasierten Suchsystem laut
		\autocite{art:OntBasedInterpOfKeyWords}}
		\label{img:Kommunikationsmodell}
	\end{figure*}
	
	% Kenntnisse des benutzers über die Ontologie
	Es gibt noch einige Anforderungen, die für die Qualität der Suchergebnisse relevant sind. Das sind Kenntnisse des Benutzers über den Aufbau der verwendeten Ontologien und Fähigkeit verwendete Ontologien zu erweitern. Idealerweise sollte der Benutzer über die meisten Elemente der verwendeten Ontologie gut informiert sein, um passende ontologiebasierte Anfragen zu benutzen. Wichtig ist auch die Vorstellung darüber, wie eine Ontologie aufgebaut ist. Das ermöglicht ihre korrekte Erweiterung mit dem Ziel, flexibel neue Suchanforderungen und neue Anforderungen an Inhaltsbeschreibungen der Dateien zu erfüllen. Auf jeden Fall soll ein Suchsystem als Implementierung des Konzeptes den Benutzer über die Elemente der Ontologie so informieren, dass Elemente der Ontologien bei der Formulierung der Suchanfragen ausgewählt werden können.
		
	Die Analyse des Kommunikationsmodells hat gezeigt, welche alternativen Interaktionsmöglichkeiten für das neue Suchkonzept ausgewählt werden können und welche Vor- und Nachteile sie haben. Die Entscheidung fiel auf die erste Variante, da die Formulierung der Suchanfragen in der Anfragesprache des Suchsystems nicht nur zu präziseren Ergebnissen führt, sondern auch besser von den Vorteilen von Ontologien profitieren kann. Dabei muss der entstehende Mehraufwand für den Benutzer, Suchwünsche in eine formale Sprache zu übersetzen, in irgendeiner Form kompensiert werden. Der Benutzer wird dadurch unterstützt, dass Ontologie-Elemente für Anfragen als fertige Bausteine vom System bereitgestellt werden und die Anfragesprache so definiert wird, dass sie möglichst einfach ist und wenig Lernaufwand erfordert. 
		
	\subsubsection{Ontologien und Arten des Suchverhaltens}
	\label{Ontologien und Arten des Suchverhaltens}
	In diesem Abschnitt werden unterschiedliche Arten des Suchverhaltens vorgestellt. Anschließend wird analysiert, wie Eigenschaften der Ontologien, wie Eindeutigkeit der Individuen, Taxonomien und Verbindungen zwischen Individuen (Objekt- und Dateneigenschaften), für einzelne Arten des Suchverhaltens eingesetzt werden können. Dabei werden die Eigenschaften der Ontologien genannt, die für einzelne Arten des Suchverhaltens eingesetzt werden können.
	
	Rosenfeld und Morville unterscheiden in \autocite{book:InfArchWWW} drei Arten der Suche. Sie können in Bezug auf Dateien wie folgt beschrieben werden:
\begin{enumerate}
	\item \emph{Known-item seeking} ist ein Suchverhalten, bei dem der Benutzer genau weiß, was gefunden werden muss. Die gesuchten Dateien sind ein Teil einer großen Sammlung von Dateien, die inhaltlich zu einer bestimmten Domäne gehören. Das Suchergebnis soll eine kleine Gruppe oder eine einzige Datei sein, deren Inhalt genau in der Anfrage spezifiziert ist. Ein Beispiel dazu: eine Sammlung enthält viele wissenschaftliche Texte zum Thema Insekten. Der Benutzer will nur die Texte finden, wo es um südamerikanische Ameisen geht, die ein bestimmtes Gruppenverhalten haben. 
	\item Das zweite Suchverhalten heißt \emph{exploratory seeking}. In dem Fall werden passende Dateien zu einem Thema gesucht. Es wird erwartet, dass die Anzahl der gefundenen Dateien groß wird und im nächsten Schritt passende Dateien manuell ausgewählt werden können oder als Zwischenergebnisse für die weitere Suche verwendet werden können. Ein Beispiel dazu ist die Suche in einer Fotosammlung nach passenden Bildern für einen Artikel. Die gesuchten Fotos können beispielsweise alle Gebäude des 19. Jahrhunderts sein unabhängig davon, wo sie sich befinden und welche Funktion haben. Das gesuchte Bild wird aus einer großen Menge der gefundenen Bildern manuell ausgewählt.
	\item Bei einem \emph{exhaustive research} werden ebenfalls viele Dateien gesucht, die inhaltlich zu einem bestimmten Thema passen. Der Unterschied zur \emph{exploratory seeking} besteht darin, dass der Benutzer sich mit dem Thema gut auskennt und Anfragen sehr gut formulieren kann. Im Gegenteil zur \emph{exploratory seeking} werden hier hauptsächlich \emph{erwartete Suchergebnisse} geliefert.
\end{enumerate}
		
	Die von Rosenfeld und Morville angebotene Klassifikation des Suchverhaltens teilt sie nach Zielen und Präzision der Anfrageformulierung auf. Der Benutzer kann entweder nach einigen  konkreten Dateien suchen und das Ergebnis wird von ihm mehr oder weniger erwartet oder es wird nach Dateien mit semantisch ähnlichen Inhalt gesucht. Die Anfragen sollen im Falle \emph{known-item seeking} so formuliert werden, dass die meisten Dateien aussortiert und nur die wenigen mit passender Inhaltsbeschreibung als Ergebnis angeboten werden. Bei \emph{exploratory seeking} sind allgemeine Begriffe in Anfragen einzusetzen, die Kategorien oder Klassen anderer Begriffe sind. 
	
	% Das vielleicht in eigenen Kapitel
	Bei Betrachtung einer OWL-Ontologie aus Sicht des Nutzens für unterschiedliche Suchverhalten kann festgestellt werden, dass die Qualität der Suchergebnisse vor allem von drei Vorteilen profitiert: Eindeutigkeit der Individuen, Taxonimien und Verbindungen zwischen Individuen (Objekt- und Dateneigenschaften in OWL). Im Folgenden wird der Nutzen dieser Vorteile für unterschiedliche Arten des Suchverhaltens untersucht.
	
	Wenn wir eine OWL-Ontologie aus der Sicht des Nutzens für unterschiedliche Suchverhalten betrachten, kann festgestellt werden, dass vor allem drei Vorteile für bessere Suchergebnisse ausgenutzt werden können: Eindeutigkeit der Individuen, Taxonimien und Verbindungen zwischen Individuen(Objekt- und Dateneigenschaften in OWL). Im Folgenden wird der Einsatz von erwähnten Vorteilen für unterschiedliche Arten des Suchverhaltens untersucht.
	
	Um möglichst gute Ergebnisse bei \emph{known-item seeking} zu erzielen, sollen Individuen der Ontologien eingesetzt werden. Die Eigenschaften und  Taxonomien können  auch für das \emph{known-item seeking} eingesetzt werden. Eine Taxonomie ist hier nur dann sinnvoll anzuwenden, wenn sie viele spezielle Kategorien enthält, zu denen nur wenige Individuen gehören oder auch wenn man Schnittmengen der Individuen bildet, die zu unterschiedlichen Klassen gehören. Die Eigenschaften erlauben es, die Menge der gesuchten Dateien dadurch sehr stark einschränken, dass man beispielsweise für eine bestimmte Eigenschaft nach unbekannten Subjekten bei einem bekannten Objekt sucht. Möglich ist auch die Suche nach allen Individuen, die durch eine Eigenschaft mit anderen Individuen verbunden sind oder nach allen Individuen, die als Objekte der Eigenschaft für bestimmte Subjekte auftreten. Ein kleines Beispiel zur Nutzung der Eigenschaften: angenommen, eine Ontologie enthält die Eigenschaft \emph{befindet sich in} und der Benutzer formuliert folgende Anfrage: alle Individuen, die Subjekt der Eigenschaft sind, so, dass das Objekt der Eigenschaft \emph{befindet sich in} das Individuum \emph{Deutschland} ist. Das Ergebnis soll aus Dateien bestehen, die in Ihren Metadaten bestimmte aktivierte Individuentags haben. Diese Tags müssen Individuen repräsentieren, die die Eigenschaft \emph{befindet sich in} mit dem Wert \emph{Deuschland} haben. Im angeführten Beispiel können Dateien gefunden werden, die zum Beispiel mithilfe der Individuentags mit den Namen \emph{Berlin} und \emph{Rhein} beschrieben sind.
	
	Für \emph{exploratory seeking} und \emph{exhaustive research} sind vor allem Taxonomien sehr nützlich, weil das System bei diesen Suchen möglichst viele ähnliche Dateien als Ergebnis liefern soll. Die Anfrage kann bei der Suchart Begriffe enthalten, die Klassen oder Kategorien einer Ontologie repräsentieren. Bei der Verwendung von Taxonomien ist zu berücksichtigen, dass keine unnötigen Ergebnisse geliefert werden, die inhaltlich zu allgemeineren Kategorien passen. Das kann dadurch erreicht werden, dass zusätzlich zu bereits gefundenen Dateien nur diejenige Dateien gefunden werden, die inhaltlich nur mit spezielleren und nicht mit allgemeineren Klassen einer Ontologie in Verbindung stehen.
		
	Alle vorgestellten Sucharten können mithilfe der Verwendung von Individuen, Taxonomien und Eigenschaften der Ontologien verbessert werden. Für \emph{known-item seeking} sind vor allem Individuen und Eigenschaften der Ontologien und für die anderen zwei Sucharten Taxonomien zu verwenden. Das bedeutet nicht, dass Eigenschaften für \emph{exploratory seeking} oder Taxonomien für \emph{known-item seeking} nicht eingesetzt werden können. Im Gegenteil, denn Taxonomien und Eigenschaften lassen sich kombinieren um passende Suchergebnisse für alle drei Sucharten zu erreichen. Dafür sollte ein Suchsystem komplexe Anfragen erlauben, die aus mehreren Teilen bestehen können. Die einzelnen Teilergebnisse der Anfragen sollten durch Mengenoperatoren verknüpfbar gemacht werden.

	\subsubsection{Ontologiebasierte Anfragesprache DOQL}
	\label{Ontologiebasierte Anfragesprache DOQL}
	
	In Abschnitt \ref{Formale Anfragesprache statt Stichwörter} (Formale Anfragesprache statt Stichwörter) wurde gezeigt, dass es für eine ontologiebasierte Suche vorteilhaft ist die formale Sprache der Interpretation von Stichwortlisten zu bevorzugen. Der entstehende Aufwand für Benutzer kann dadurch reduziert werden, dass die Anfragesprache einfach erlernbar ist und der Benutzer bei der Formulierung der Anfragen in Implementierungen des Konzeptes unterstützt wird. So können beispielsweise ontologiebasierte Elemente der Anfragesprache wie fertige Bausteine aus einer Liste auswählbar gemacht werden.
	
	Es wurde auch entschieden eine \emph{neue} Anfragesprache für das Konzept zu definieren. Die bereits existierende Anfragesprachen für OWL-Ontologien, OWL-QL, SPARQL und SQWRL, werden für Kommunikation zwischen Software-Agenten eingesetzt und haben eine für Endbenutzer zu komplexe Syntax. Aus diesem Grund konnten sie als Alternative zu Anfragen in Form von Stichwörtern oder Anfragen in einer neu definierten benutzerfreundlichen Anfragesprache nicht betrachtet werden.
	
	Die entwickelte ontologiebasierte Anfragesprache heißt DOQL (Abkürzung für \textbf{D}ynamic \textbf{O}ntology based \textbf{Q}uery \textbf{L}anguage). Die Anfragesprache ist ontologiebasiert, was bedeutet, dass ihre Elemente auf einer im Moment der Anfrage eingebundenen Ontologie basieren. Außerdem ist sie dynamisch, weil ihre Elemente abhängig von der eingebundenen Ontologie sind und sie bei der Einbindung einer anderen Ontologie vom Suchsystem automatisch ersetzt werden. Anfragen, die aus Elementen einer Ontologie bestehen, die nicht mehr eingebunden ist, werden vom Suchsystem als nicht valide betrachtet und nicht ausgeführt.
	 
	Für den ersten Schritt des Suchvorgangs muss DOQL ermöglichen, dass anhand von angegebenen Bedingungen eine Teilmenge von Klassen und Individuen einer Ontologie aus der Gesamtmenge von Elementen ausgefiltert wird. Diese ausgefilterte Ergebnismenge kann dann in die ontologiebasierten Tags umgewandelt und bei der Suche nach Dateien eingesetzt werden. Der komplette Suchvorgang wird in Abschnitt \ref{Bearbeitung der Suchanfragen} (Bearbeitung der Suchanfragen) ausführlich beschrieben.
		
	Um Individuen und Klassen aus der eingebundenen Ontologie auszufiltern, bietet\\ DOQL einen Satz von einfachen Bausteinen, die im Folgenden Filter genannt werden. Angewendet auf eine Ontologie liefern diese Filter folgende Ergebnismengen bestehend aus Individuen und Klassen dieser Ontologie :
		\begin{enumerate}
			\item eine Menge bestehend aus einem bestimmten Individuum und allen Individuen, die
			als	äquivalente Individuen definiert sind,
			\item eine Menge bestehend aus Individuen einer Klasse, ihrer Unterklassen dieser
			und 	allen betroffenen Unterklassenelementen,
			\item eine Menge aller Individuen, die Subjekte einer Objekteigenschaft für ein
			bestimmtes Objekt sind,
			\item eine Menge aller Individuen, die Objekte einer Objekteigenschaft für ein
			bestimmtes Subjekt sind,
			\item eine Menge aller Individuen, die eine bestimmte Objekteigenschaft oder
			eine erbende Objekteigenschaften haben (Subjekte der Objekteigenschaft und der
			erbenden Objekteigenschaften),
			\item eine Menge aller Individuen, die Objekte einer bestimmten Objekteigenschaft
			und der 	erbenden Objekteigenschaften sind,
			\item eine Menge von aller Individuen, die Objekt oder Subjekt einer bestimmten
			Objekteigenschaft oder der erbenden Objekteigenschaften sind,
			\item eine Menge aller Individuen, die eine bestimmte Dateneigenschaft oder erbende
			Dateneigenschaften haben oder
			\item eine Menge aller Individuen, die eine Dateneigenschaft mit einem bestimmten
			Wert haben.
		\end{enumerate}
		
	Filter werden so definiert, dass ihre Anwendung möglichst einfach und intuitiv ist. Bei den Ergebnismengen 1 und 2 werden Individuen- bzw. Klassentags als Filter eingesetzt. Zum Beispiel der Filter \emph{meineOntologie/IN\_Gebiet} liefert das Individuumtag \emph{meineOntologie/IN\_Gebiet} und alle Tags, die mithilfe der OWL-Eigenschaft \emph{owl:sameAs} äquivalent zu \emph{meineOntologie/IN\_Gebiet} definiert sind, z.B. \emph{meineOntologie/IN\_Gegend} und \emph{meineOntologie/IN\_Areal}.
	
	%Synonyme und Homonyme
	Die Berücksichtigung von Äquivalenzen bei Individuentags während der Suche hilft synonyme Begriffe richtig zu behandeln und in einem bestimmten Kontext unpassende Synonyme aus der Suche auszuschließen. Synonyme Begriffe können in OWL explizit als äquivalente Individuen definiert werden. 
	
	Auch Homonyme werden in einem ontologiebasierten Suchsystem korrekt behandelt. Dadurch, dass Homonyme meistens zu unterschiedlichen Wissensdomänen gehören, werden Individuen, die homonyme Begriffe repräsentieren, in unterschiedlichen Ontologien definiert und erhalten demzufolge bei gleichem Namen unterschiedliche Ontologie-Prefixe. Die folgenden beiden Individuen-Tags werden vom Suchsystem immer korrekt voneinander unterschieden und korrekt entsprechend ihrer Semantik behandelt: \emph{hunderassenOntologie/IN\_Boxer} und \emph{sportOntologie/IN\_Boxer}.
	
	Klassenfilter, die effektiv für unscharfe Suche eingesetzt werden können, liefern drei Gruppen von Tags. Wenn zum Beispiel ein Klassenfilter \emph{meineOntologie/CL\_Land} angegeben wird, könnten folgende Elemente zurückgeliefert werden:
		\begin{itemize}
			\item alle Individuen der Klasse \emph{Land}, z.B. \emph{Deutschland},
			\emph{Italien} usw.
			\item alle Individuen aller Unterklassen der Klasse \emph{Land}, z.B. wenn die
			Klasse 	\emph{Land} die Unterklasse \emph{nicht-anerkanntes Land} hat, dann werden
			alle Individuen	dieser Unterklasse zurückgeliefert, z.B. \emph{Cookinseln} u.a.
			\item alle Unterklassenelemente, z.B. \emph{meineOntologie/CL\_nicht anerkanntes
			Land} u.a.
		\end{itemize}
		
	Die Filter von Objekt- und Dateneigenschaften (3 bis 9) verwenden die Abkürzungen PR (engl.
\emph{properties}) für Objekteigenschaften und DP (engl. \emph{data properties}) für Dateneigenschaften in den Filternamen.
		
	Bei den Filtern 3,4,5,6 und 7, die Objekteigenschaften als Kriterium nutzen, wird ein Filter mit Parametern für Subjekt und Objekt der Objekteigenschaft definiert. Die Parameter der Objekteigenschaften werden in runden Klammern angegeben und durch Kommata voneinander getrennt. 
	
	Außerdem werden zwei Schlüsselwörter benötigt, die \emph{alle gesuchten und unbekannten} Subjekte bzw. Objekte einer Objekteigenschaft abhängig von einem bekannten zweiten Parameter repräsentieren oder Individuen, die \emph{alle} Individuen als Objekt/e oder Subjekt/e einer Objekteigenschaft unabhängig von dem zweiten Parameter ausdrücken können. Im ersten Fall wird \emph{?} (Fragezeichen) als ein spezielles Symbol verwendet. Im zweiten Fall wird Schlüsselwort \emph{all} in Kombination mit \emph{?} benutzt. \emph{all} kann in Filtern für Objekteigenschaften nur zusammen mit \emph{?} verwendet werden. Das Schlüsselwort \emph{all} drückt aus, dass alle Individuen gesucht werden, die Subjekt bzw. Objekt einer Objekteigenschaft sind. Das Fragezeichen wird in dem Fall als \emph{beliebige Individuen} interpretiert.
		
	Folgende Liste enthält Beispiele der Verwendung von Filtern für Objekteigenschaften mit Angabe der Ergebnismengen bestehend aus Individuentags:
	\begin{itemize}	
		\item 
		\begin{lstlisting}	
ontologieName/PR_eigenschaftsName	(?, ontologieName/IN_individualName)
		\end{lstlisting}
			(Ergebnismenge 3: alle Individuen, die Subjekte der Objekteigenschaft für ein bestimmtes Objekt sind),
		\item 
		\begin{lstlisting}	
ontologieName/PR_eigenschaftsName	(ontologieName/IN_individualName, ?)
		\end{lstlisting}			
			(Ergebnismenge 4: allen Individuen, die Objekte der Objekteigenschaft für ein bestimmtes Subjekt sind),
		\item 
		\begin{lstlisting}	
ontologieName/PR_eigenschaftsName	(all, ?)
		\end{lstlisting}	
			(Ergebnismenge 5: alle Individuen, die eine bestimmte Objekteigenschaft oder die erbenden Objekteigenschaften haben(Subjekte der Eigenschaft oder erbender Eigenschaften),
		\item 
		\begin{lstlisting}	
ontologieName/PR_eigenschaftsName	(?, all)
		\end{lstlisting}	
			(Ergebnismenge 6: alle Individuen, die Objekte einer bestimmten Objekteigenschaft oder der erbenden Objekteigenschaften sind),
		\item 
		\begin{lstlisting}	
ontologieName/PR_eigenschaftsName	(?, ?)
		\end{lstlisting}	
			(Ergebnismenge 7: alle Individuen, die Objekt oder Subjekt einer bestimmten Objekteigenschaft oder der erbenden Objekteigenschaften sind).	
		\end{itemize}
		
	Die letzten beiden Filter für Dateneigenschaften, Filter 8 und 9, benötigen genauso wie die Filter für Objekteigenschaften benötigen zusätzliche Angaben. Diese erhalten sie in Form eines Arguments in runden Klammern. Als spezielles Symbol für einen beliebigen Wert wird \emph{?} (Fragezeichen) verwendet, sonst kann eine beliebige Zeichenkette als Wert einer Dateneigenschaft angegeben werden.
	
	Unten werden Beispiele für die Verwendung von Filtern für Dateneigenschaften mit Angabe der Ergebnismengen bestehend aus Individualtags gezeigt:
		
	\begin{itemize}
		\item 
		\begin{lstlisting}	
ontologieName/DP_eigenschaftsName	(?)
		\end{lstlisting}	
			(Ergebnismenge 8: alle Individuen, die eine bestimmte Dateneigenschaft oder die erbenden Dateneigenschaften haben).
		\item 
		\begin{lstlisting}	
ontologieName/DP_eigenschaftsName	(<Wert der Dateneigenschaft, z.B eine Zahl>)
		\end{lstlisting}	
			(Ergebnismenge 9: allen Individuen, die eine Dateneigenschaft mit einem bestimmten Wert haben).
	\end{itemize}	
	
	Um die Mächtigkeit der Suchanfragen und somit die Präzision der Suchergebnisse zu erhöhen, können die Teilergebnisse der einzelnen Operationen mithilfe der Mengenoperatoren \emph{UND} und \emph{ODER} miteinander verknüpft werden. Wie in der Mengenlehre werden die Operanden des Operators \emph{UND} stärker als die des Operators \emph{ODER} gebunden.
	
	Eine formale Beschreibung von DOQL in Extended Backus–Naur Form wird in Listing \ref{EBNF der Anfragesprache} gezeigt.
	
	\begin{lstlisting}[caption={Extended Backus–Naur Form der Anfragesprache},label=EBNF der Anfragesprache,captionpos=b]
<Anfrage> = <Filter> { <Mengenoperator> <Filter> };	
<Mengenoperator> = "AND" | "OR" | "and" | "or";
<Filter> = <Filter Individuum> | <Filter Klasse> | <Filter Eigenschaft>;
<Filter Individuum> = <Individuumname>;
<Filter Klasse> = <Klassenname>;
<Filter Objekteigenschaft> = <Objekteigenschaftsname> "(" <OE_Parameter> "," <OE_Parameter> ")";
<Filter Dateneigenschaft> = <Dateneigenschaftsname> "(" <DE_Parameter> ")";	
<OE_Parameter> = "?" | "all" | <Individuumname>;
<DE_Parameter> = "?" | beliebige Zeichen;
<Klassenname> = <Ontologiedatei> "/CL_" <Name des Ontologieelements>;
<Individuumname> = <Ontologiedatei> "/IN_" <Name des Ontologieelements>;
<Objekteigenschaftsname> = <Ontologiedatei> "/PR_" <Name des Ontologieelements>;
<Dateneigenschaftsname> = <Ontologiedatei> "/DP_" <Name des Ontologieelements>;
<Ontologiedatei> = Name der Ontologiedatei ohne .owl Erweiterung 
<Name des Ontologieelements> = URI Fragmentbezeichner;
(* z.B. 'Auto' in http://www.example.org/ontologies/2012/example.owl#Auto *)
	\end{lstlisting}	
	
	Anhand eines Beispiels wird die Verwendung der Anfragesprache erklärt. Angenommen eine Ontologie enthält Klassen \emph{Mannschaftssport}, \emph{Individualsport} und \emph{Sportgerät}, die Eigenschaft \emph{benutzt\_Sportgeraet} sowie zahlreiche Individuen, die zu den erwähnten Klassen gehören. Der Benutzer möchte alle Dateien finden, bei denen es um Mannschaftssportarten mit einem Ball als Sportgerät geht. Die Anfrage für diesen Suchwunsch wird so aussehen: 
		\begin{lstlisting}
ontologieName/CL_Mannschaftssport AND
ontologieName/PR_benutzt_Sportgeraet(?, ontologieName/IN_Ball)
		\end{lstlisting}	

\subsection{Extraktion von Metadaten}
\label{Extraktion von Metadaten}
Eine manuelle Beschreibung der Dateiinhalte kann sehr aufwendig und zeitintensiv sein, selbst wenn sie nur darin besteht, passende ontologiebasierte Tags im Metadateneditor zu aktivieren bzw. zu deaktivieren, kann sehr aufwendig und zeitintensiv sein. Aus diesem Grund muss eine automatisierte Lösung für die Extraktion der bereits vorhandenen Metadaten und ihre Zusammenführung mit den Tags der eingebundenen Ontologien gefunden werden.

Eine mögliche Lösung kann darin bestehen, standardisierte Metadaten von Dateien automatisiert zu lesen und einige von ihnen mithilfe vordefinierter Ontologien zu bearbeiten, um neue Informationen über den Inhalt zu finden. Anschließend können alle gelesenen, alle aus einer vordefinierten Ontologie gewonnenen und alle aus einer eingebundenen Ontologie extrahierten Metadaten in Form von Individuum-Tags in ontologiebasierten Metadaten der bearbeitenden Datei gespeichert werden. Alle gelesenen und alle aus einer vordefinierten Ontologie gewonnenen Tags werden sofort aktiviert. Die Tags der eingebundenen Ontologie, egal ob sie bereits vor der Extraktion der Metadaten vorhanden waren oder erst während der Extraktion von Metadaten angelegt wurden, werden einzeln mit den neuen aktivierten Tags verglichen. Tags der eingebundenen Ontologie, die gleiche Zeichenketten in ihren Namen beinhalten, werden aktiviert. Andere werden mit vorhandenen Metadaten zusammengeführt bzw. zu den Metadaten hinzugefügt und bleiben deaktiviert. Darüber hinaus ist es für das System wichtig die Individuen-Tags von extrahierten Metadaten zu speichern, um den Benutzer später bei der Suche mit fertigen Individuen-Filtern zu unterstützen. 

Im Folgenden wird der Extraktionsvorgang anhand eines einfachen Beispiels erläutert und in Abbildung \ref{img:Beispiel eines Extraktionsvorgangs} veranschaulicht. Angenommen die Extraktionskomponente eines ontologiebasierten Suchsystems liest die Metadaten einer Bilddatei, die die Schlüsselwörter \emph{Rhein} und \emph{Schiff} sowie den Ort der Aufnahme (\emph{Konstanz}) enthält. Die Komponente ist in der Lage mithilfe einer vordefinierten Ontologie das Land, das Kontinent und andere Informationen passend zu einem Ort herauszufinden. Die Komponente findet Begriffe \emph{Deutschland}, \emph{EU} und \emph{Europa}. Diese neuen Begriffe, der Ort \emph{Konstanz} und die gelesenen Schlüsselwörter \emph{Rhein} und \emph{Schiff} werden als neue Individuum-Tags zu den ontologiebasierten Metadaten der Datei hinzugefügt und sofort aktiviert. Neben diesen Tags werden auch alle Individuum- und Klassentags einer im Idealfall selbst entwickelten Ontologie zu den ontologiebasierten Metadaten hinzugefügt. Jedes Individuum-Tag der eingebundenen Ontologie wird dabei mit jedem Tag der gerade hinzugefügten Individuum-Tags \emph{Rhein}, \emph{Schiff}, \emph{Deutschland}, \emph{EU} und \emph{Europa} verglichen und aktiviert, wenn der Tagname die Zeichenkette der aufgezählten Individuum-Tags enthält. 

\begin{figure*}[htbp]
	\centering
	\includegraphics[width=13cm]{figures/Extraktionskomponente.pdf}
	\caption{Beispiel eines Extraktionsvorgangs}
	\label{img:Beispiel eines Extraktionsvorgangs}
\end{figure*}

Das Ergebnis der Extraktion ist eine neue bzw. erweiterte Datei mit ontologiebasierten Tags, die aus Metadaten und einer eingebundenen Ontologie extrahiert wurden. Alle zum Inhalt der Bilddatei passenden Tags sind bereits aktiviert und der Benutzer kann die Richtigkeit der Extraktion kontrollieren oder sofort mit der ontologiebasierten Suche beginnen. Bei der Extraktion wurden die extrahierten und aus der Analyse der vordefinierten Ontologie stammende Tags als Individuum-Filter gespeichert und können somit vom Benutzer bei der Suche verwendet werden.

Die Extraktion von standardisierten Metadaten kann dadurch verbessert werden, dass mehrere vordefinierte Ontologien bei der Suche nach neuen relevanten Begriffen eingesetzt werden. Auch die Abdeckung von mehreren Metadatenstandards und Dateiformaten kann dazu führen, dass immer weniger manueller Aufwand mit der Beschreibung der Dateieninhalte für ontologiebasierte Suche verbunden wird. 

Die erwähnten Verbesserungsmöglichkeiten haben zwar ein großes Potential, aber sie haben auch einige wesentliche Nachteile. Erstens kann eine Extraktion der Metadaten wie jeder automatisierter Vorgang fehlerhaft sein und deshalb sollten die Ergebnisse in kritischen Fällen manuell kontrolliert werden. Zweitens ist der Erfolg einer Extraktion davon abhängig, wie gut bereits vorhandene Metadaten beschrieben sind. Qualitativ gute Metadaten werden am besten manuell beschrieben, was wieder mit großem Aufwand verbunden ist.

\subsection{Überblick über das Konzept}
\label{Zusammenfassung des Konzepts}

	Dieser Abschnitt stellt einen Überblick über einzelne Lösungen und Ideen des Kapitels \ref{Konzept der Suche} dar. Hier werden die wichtigsten Punkte des Konzepts nochmal erläutert und die Hauptelemente, konkret die ontologiebasierte Suche und die Verwaltung der ontologiebasierten Metadaten, veranschaulicht.
	
	%Grundidee
	Das vorgestellte Konzept basiert auf der Idee, dass die Metadaten und die Anfragesprache in einem ontologiebasierten Suchsystem für Dateien \emph{ontologiebasiert} sein sollen, damit eine volle Ausnutzung von Ontologien und somit bessere Suchergebnisse erzielt werden können. Das verbessert maschinelle Bearbeitung von Metadaten und Interpretation von Anfragen. Das Konzept löst auch Probleme, die bei der Verwendung von Synonymen und Homonymen auftreten können.
	
	% Metadaten
	Metadaten der Dateien sollen entsprechend dieses Konzepts ausschließlich aus Tags bestehen, die selbst auf Individuen- und Klassenelementen der vorhandenen OWL-Ontologien basieren. Für jede Datei wird eine Metadatendatei mit der Erweiterung \emph{.ose} im selben Verzeichnis angelegt. Jede beschriebene Datei soll in ihren Metadaten alle möglichen Tags von Ontologien beinhalten, die für die Beschreibung verwendet wurden. Bei der Beschreibung müssen einzelne dieser Tags aktiviert werden. Das Konzept sieht außerdem vor, dass Ontologien vom Benutzer erweitert werden, wenn sie neuen Suchanforderungen nicht mehr entsprechen. Aus diesem Grund wird es empfohlen, eigene domänenspezifische Ontologien anzulegen und sie zu erweitern.
	
	%Anfragesprache
	Die Analyse des Kommunikationsmodells aus \autocite{art:OntBasedInterpOfKeyWords} hat gezeigt, dass Anfragen entweder in einer formalen Sprache des Suchsystems  oder in Form von Stichwörtern verwendet werden können, und dass es aus vielen Gründen vorteilhaft für die Qualität der Suchergebnisse ist, eine formale Anfragesprache zu verwenden. Außerdem sollte diese Anfragesprache ontologiebasiert sein um von allen Vorteilen von Ontologien zu profitieren. Zusätzlich wurde geprüft, welche Eigenschaften der Ontologien für unterschiedliche Suchverhalten ausgenutzt werden können. Als Realisierung der gesammelten Ideen und Lösungen wurde eine ontologiebasierte, dynamische Anfragesprache DOQL entwickelt. Diese Sprache ist dynamisch, d.h. sie basiert auf der aktuell eingebundenen Ontologie und bietet Filter zur Extraktion von semantisch passenden Tags aus der Ontologie. Diese Tags werden bei der Suche in den Metadaten der Dateien verwendet. Dabei werden sie mit den Metadaten-Tags verglichen und bei einer Übereinstimmung mit einem aktivierten Tag wird die entsprechende Datei zu Suchergebnissen hinzugefügt.
	
	% Extraktion von IPTC-Metadaten
	Darüber hinaus bietet das Konzept die Möglichkeit, bereits vorhandenen IPTC-Metadaten innerhalb des ontologiebasierten Systems zu nutzen. Geographische IPTC-Metadaten werden nicht nur extrahiert, sondern auch mithilfe einer vordefinierten Ontologie für geographische Daten erweitert und anschließend in Metadaten als aktivierte ontologiebasierte Tags integriert.
	
	%Abbildungen
	Die ontologiebasierte Suche und die Verwaltung der ontologiebasierten Metadaten sind in Abbildung \ref{img:KonzeptSucheUndMetadatenverwaltung} gezeigt. Die Zusatzfunktion, namentlich die Extraktion von IPTC-Metadaten, wurde in Abschnitt \ref{Extraktion von Metadaten} beschrieben und ist als Beispiel eines Extraktionsvorgangs in Abbildung \ref{img:Beispiel eines Extraktionsvorgangs} veranschaulicht.
\begin{figure*}[htbp]
	\centering
	\includegraphics[width=14cm]{figures/vorgehensweiseKonzept.pdf}
	\caption{Konzept der ontologiebasierten Suche nach Dateien}
	\label{img:KonzeptSucheUndMetadatenverwaltung}
\end{figure*}
		
		\newpage
		Das vorgestellte Konzept hat eine Reihe von Einschränkungen, die Grenzen des Konzepts
	definieren sich wie folgt:
	\begin{itemize}		
		\item Anfragen in DOQL können nicht in Form von Stichwörtern gestellt werden. Nur DOQL-
		Filter werden akzeptiert.
		\item Das Anlegen von neuen Tags ohne eine vorläufige Erweiterung entsprechender
		Ontologie ist nicht möglich.
		\item Eine automatisierte Erweiterung von Ontologien nach dem Anlegen von Individuen- und
		Klassentags im Metadateneditor ist nicht vorgesehen.
		\item DOQL erlaubt es nicht, Wertebereiche als Filter-Parameter zu verwenden. Die Filter
		\emph{ontologie/DP\_bevoelkerung(>70000)} und
		\emph{ontologie/DP\_bevoelkerung(10000-70000)} wären nicht valide.
		\item DOQL-Filter für Individuen können nur durch die Verwendung der Eigenschaft
		\emph{sameAs} zusätzliche semantisch passende Individuen-Tags in einer Ontologie finden und können somit sehr begrenzt für unscharfe Suche eingesetzt werden. Die Ursache liegt darin, dass
		das System die Semantik von OWL-Eigenschaften, die Individuen miteinander verbinden, nicht interpretieren kann. So kann der 	Filter \emph{ontologie/IN\_Gebäude} erfolgreich bei einer
		unscharfen Suche eingesetzt werden um äquivalente Individuen-Tags \emph{ontologie/IN\_Gebäude} und \emph{ontologie/IN\_Bauwerk} zu finden. Der Filter findet allerdings keine Tags \emph{ontologie/IN\_Fassade} und \emph{ontologie/IN\_Raum}, weil OWL-Eigenschaften, die Begriffe \emph{Fassade} und \emph{Raum} mit dem Begriff \emph{Gebäude} verbinden, vom Suchsystem als sinnlose Zeichenketten betrachtet werden. Aus diesem Grund können passende Eigenschaften nicht aussortiert werden.
	\end{itemize}
	
	In einzelnen Fällen können die aufgezählten Einschränkungen durch eine mögliche Weiterentwicklung von DOQL oder Metadateneditor überwunden werden.
	
\newpage	
\section{Ontologiebasierte Suchanwendung}
\label{Ontologiebasierte Suchanwendung}

	Das in Kapitel \ref{Konzept der Suche} vorgestellte Konzept für die Suche nach Dateien durch die Verwendung von Ontologien wurde als Prototyp in Form der Java-Desktop-Anwendung \emph{Ontology Based Search Engine} (OBSE) realisiert. Sie bietet die folgenden drei Funktionen: 
	\begin{enumerate}
		\item Bearbeiten der Metadaten,
		\item Extrahieren von IPTC-Metadaten aus JPG-, TIFF- und PSD-Dateien und
		\item Ontologiebasiertes Suchen mithilfe der Anfragesprache DOQL.
	\end{enumerate}
	
	Der Prototyp bietet neben grafischen Benutzeroberfläche (GUI) auch eine Programmierschnittstelle an. Damit kann OBSE über Java-Schnittstellen auch von externen Software-Systemen genutzt werden. Wie bereits in \ref{Zusammenfassung des Konzepts} erklärt, wird für geographische Daten der Dienst \emph{geonames.org} verwendet. Zur Kommunikation mit diesem Web-Service wird eine Internetverbindung vorausgesetzt. Die Komponenten des implementierten Suchsystems werden in Abbildung \ref{img:Architektur der Suchanwendung} veranschaulicht.
	
	\begin{figure*}[htbp]
			\centering
			\includegraphics[width=14cm]{figures/ArchitekturOBSE.pdf}
			\caption{Architektur der Desktop-Suchanwendung OBSE}
			\label{img:Architektur der Suchanwendung}
	\end{figure*}
	
	In den folgenden Abschnitten werden die drei Funktionen von OBSE beschrieben, seine Programmierschnittstelle vorgestellt und verwendete Bibliotheken aufgeführt.
	
		\subsection{Funktion 1: Die ontologiebasierte Suche}
		Die Hauptfunktion der Anwendung ist die Suche nach Dateien mithilfe der eingebundenen Ontologien. Die Suchfunktion wurde so implementiert, dass der Benutzer bei der Formulierung der Abfrage durch fertige ontologiebasierte Elemente der Anfragesprache unterstützt wird. Somit ist eine erfolgreiche ontologiebasierte Suche auch für diejenigen Benutzer möglich, die nur eine grobe oder gar keine Vorstellung über die eingebundene Ontologie haben.
		
	Die Suchfunktion ist in das Hauptfenster der Anwendung integriert (siehe Abbildung \ref{img:Hauptfenster der Desktop-Suchanwendung}). Im oberen Bereich des Fensters können die Ontologie in einer OWL-Datei (\emph{OWL file}) eingebunden und das Arbeitsverzeichnis (\emph{Root folder}) ausgewählt werden. Die ausgewählte Ontologie wird bei der Suche berücksichtigt und es wird nur nach Dateien gesucht, die sich im Arbeitsverzeichnis bzw. in seinem Verzeichnisbaum befinden. Der Bereich zum Formulieren der Suche ist in zwei Komponenten aufgeteilt: Links befindet sich die Liste aller zur Verfügung stehenden ontologiebasierten Elemente, rechts davon befindet sich ein Textbereich für die Suchanfrage. Wird ein Element aus der Liste angeklickt, wird es an der aktuellen Cursor-Position im Textfeld eingefügt. Das Textfeld erlaubt manuelle Eingaben, so dass Property-Elemente noch um Parameter ergänzt und Mengenoperatoren zwischen Elementen hinzugefügt werden können. Über den Button \emph{Search} wird die Suche gestartet. Die Ergebnisse werden im unteren Teil des Hauptfensters angezeigt. Wird in der Liste der gefundenen Dateien eine Bilddatei ausgewählt, wird das Bild als Vorschau rechts neben der Liste angezeigt. Ein Doppelklick auf den Dateinamen öffnet die Datei im verknüpften Programm.
		
		\begin{figure*}[htbp]
			\centering
			\includegraphics[width=14cm]{figures/hauptfenster.png}
			\caption{Hauptfenster der Desktop-Suchanwendung}
			\label{img:Hauptfenster der Desktop-Suchanwendung}
		\end{figure*}
		
		\subsection{Funktion 2: Bearbeiten der Metadaten}
		
	OBSE ermöglicht die Änderung der Zustände von ontologiebasierten Tags. Die entsprechende Funktion ist über den Menüpunkt \emph{Metadata Tool} im \emph{Tools}-Menü zu finden. Der Editor öffnet sich in einem neuen Fenster (siehe Abbildung \ref{img:fensterMetadataTool}). Dieses ist in drei Bereiche aufgeteilt. Links befinden sich die Dateien und (falls vorhanden) ihre zugehörigen Metadaten-Dateien mit der Erweiterung \emph{ose}. In der Mitte werden Vorschaubilder der ausgewählten Datei angezeigt. Rechts werden die ontologiebasierte Tags der ausgewählten Datei tabellarisch dargestellt. Jedes Tag nimmt dabei einen der beiden Zustände an: \emph{aktiv} und \emph{nicht aktiv}. Zum Ändern des Zustands muss lediglich die entsprechende Checkbox aktiviert bzw. deaktiviert werden. Tags sollten entsprechend den Empfehlungen des Abschnitts \ref{Ontologiebasierte Metadaten} aktiviert werden.
		
	\begin{figure*}[htbp]
		\centering
		\includegraphics[width=14cm]{figures/metadataTool.png}
		\caption{Metadata-Beschreibungstool}
		\label{img:fensterMetadataTool}
	\end{figure*}
	
	Genauso wie die Suche, arbeitet der Metadaten-Editor auf der im Hauptfenster ausgewählten Ontologie und innerhalb des angegebenen Arbeitsverzeichnisses. Metadaten einer Datei werden beim Bearbeiten bei Bedarf durch die Tags der eingebundenen Ontologie ergänzt, falls sie noch nicht in den Metadaten enthalten sind. Falls ein Individuum oder eine Klasse aus der eingebundenen Ontologie entfernt wird, wird das entsprechende Tag auch in den zum Bearbeiten geöffneten Metadaten entfernt.
		
	Die durchgeführten Änderungen können über den Button \emph{Save Changes} in den jeweiligen \emph{*.ose}-Dateien gespeichert werden. Wenn Metadaten einer Datei komplett gelöscht werden sollen, kann die entsprechende \emph{*.ose}-Datei außerhalb des Tools gelöscht werden.
		
		\subsection{Funktion 3: Extrahieren von IPTC-Metadaten aus Bilddateien}
		\label{Funktion 3: Tool zur Extraktion von IPTC-Metadaten aus Bilddateien}

	Die Anwendung enthält eine Komponente für die Extraktion standardisierter Metadaten. Die ausgelesenen Metadaten werden dabei mithilfe der vordefinierten Ontologie analysiert und anschließend in die vom System verwalteten Metadaten integriert. Eine genaue Beschreibung des Vorganges befindet sich in Abschnitt \ref{Extraktion von Metadaten} und ist in Abbildung \ref{img:Beispiel eines Extraktionsvorgangs} veranschaulicht.
		
	Es ist kaum möglich, alle Dateiformate mit integrierten Metadaten und alle Metadatenstandards abzudecken. Das Ziel dieser Komponente ist zu zeigen, dass die im Konzept beschrieben Extraktionsstrategie prinzipiell realisierbar ist und dass der Einsatz dieser Strategie zur effizienteren Inhaltsbeschreibung der Dateien führt. Exemplarisch unterstützt die Anwendung
Bilddateien in den Formaten JPG, TIFF und PSD, die ihre Inhalte in IPTC-NAA-Standard beschreiben. 
		
	Der IPTC-NAA-Standard (oft schlicht IPTC genannt) dient der Speicherung der Metadaten in einem speziellen Bereich innerhalb einer Bilddatei. Der Standard wurde vom International Press Telecommunications Council (IPTC) zusammen mit der Newspaper Association of America (NAA) 
entwickelt und ist nicht auf Bilddateien beschränkt, sondern auch für Texte, Audio und Video geeignet\autocite{book:iptcStandard}. Er definiert mehrere Metadaten-Eigenschaften (engl. Metadata Properties), die jeweils verschiedenen Sektionen zugeordnet sind \autocite{spec:iptcStandard}. Die Extraktionskomponente liest die Eigenschaft \emph{Keywords} der Grundsektion \emph{content section} und folgende Eigenschaften der zusätzlichen Sektion \emph{Description of the image}:
		\begin{itemize}
		\item \emph{Sublocation} (in diesem Feld werden spezielle Gebiete innerhalb einer Stadt, Plätze, Sehenswürdigkeiten und ähnliche Orte und Objekte angegeben)
		\item \emph{City}
		\item \emph{Province/ State}
		\item \emph{Country}
		\item \emph{Continent}
		\item \emph{Country code}(ISO3166-2)
		\end{itemize}
	
	Die gelesenen Schlüsselwörter werden im System sofort als neue Individuumtags angelegt und können anschließend bei der ontologiebasierten Suche verwendet werden. Die Metadaten der bearbeiteten Datei werden um entsprechende, voraktivierte Individuum-Tags der Form \mbox{\emph{iptcKeyword/IN\_<Schlüsselwort>}}ergänzt.
	
	Geographische Metadaten werden besonders behandelt. Die Extraktionskomponente versucht fehlende Angaben zu ergänzen, indem eine vordefinierte Ontologie abgefragt wird. Dabei wird \emph{GeoNames} verwendet, eine der größten, freien und online zugänglichen geographischen Ontologien. Sie enthält 10 Millionen geographische Namen und bietet verschiedene aufgabenspezifische Web-Services\autocite{url:GeoNames}. Die Extraktionskomponente nutzt zwei davon: \emph{countryInfo} und \emph{search}.  Die extrahierten geographischen und die mithilfe von \emph{GeoNames} gefundenen zusätzlichen Metadaten werden wie die Schlüsselwörter als Individuumtags dem System hinzugefügt. Geographische Tags haben folgende Form: \emph{iptc<IPTC-Eigenschaft>/IN\_<Wert>}. Zum Beispiel sieht ein mithilfe von \emph{GeoNames} extrahiertes Individuumtag mit dem Namen \emph{Berlin} folgendermaßen aus: \emph{iptcCity/IN\_Berlin}.

	Am Ende der Extraktion werden alle extrahierten Metadaten und alle hinzugefügten Individuumtags mit den bereits vorhandenen Tags der bearbeiteten Datei auf Ähnlichkeit untersucht. Enthält ein vorhandener Tag ähnliche Zeichenketten, wird er aktiviert.
	
	Abschließend werden folgende Statistiken angezeigt: Anzahl der bearbeiteten Bilddateien, Anzahl der angelegten und der erweiterten Metadatendateien, Anzahl hinzugefügter und Anzahl aktivierter Tags sowie die Anzahl der Tags, die entweder vor der Extraktion vorhanden waren oder aus der eingebundenen Ontologie stammen und den extrahierten Metadaten ähnlich sind. Abbildung \ref{img:Statistik zum Extraktionsvorgang} veranschaulicht den entsprechenden Dialog.
	
	\begin{figure*}[htbp]
		\centering
		\includegraphics[width=8cm]{figures/extractionStatistic.png}
		\caption{Statistik zum Extraktionsvorgang}
		\label{img:Statistik zum Extraktionsvorgang}
	\end{figure*}
	
	Das automatische Aktivieren von Tags kann zu einer fehlerhaften Beschreibung des Dateiinhalts führen. Das kann zum Beispiel dann passieren, wenn ein extrahiertes Tag einen kurzen Namen wie \emph{DE} in \emph{iptcCountryISOCode/IN\_DE} hat. Wenn die Extraktionskomponente ein existierendes Tag mit dem Namen \emph{andereOntologie/IN\_Niederlande} findet, wird es aktiviert, weil das Tag \emph{andereOntologie/IN\_Niederlande} die Zeichenkette \emph{DE} enthält. Offensichtlich ist eine solche Aktivierung des Tags falsch und soll korrigiert werden. Aus diesem Grund wird empfohlen nach der Extraktion eine manuelle Korrektur von aktivierten Metadatentags durchzuführen. Um die Kontrolle und die Korrektur zu erleichtern, führt die Statistik auch alle automatisch aktivierten Tags auf. Der Inhalt des Textbereichs lässt sich kopieren und damit für eine manuelle Korrektur verwenden.
			
\subsection{Programmierschnittstelle (API) der Anwendung}
\label{Programmierschnittstelle(API) der Anwendung}
		OBSE stellt eine Programmierschnittstelle zur Verfügung und ermöglicht anderen Software-Systemen darüber, die drei Hauptfunktionen zu nutzen. Die API wird anhand kurzer Beispiele erklärt:
		\renewcommand{\ttdefault}{pcr}
		\begin{itemize}
			\item \emph{Suchfunktion}: Um ontologiebasierte Suche durchzuführen muss zuerst eine Instanz der Klasse OWLSearchEngine erzeugt werden. Anschließend können Anfragen in DOQL mithilfe der Methode \emph{query} ausgeführt werden:
		\lstset{
		%basicstyle=\ttfamily,
		keywordstyle=\bfseries,
		language=Java, 
		aboveskip=11pt,
		belowskip=11pt,
		breaklines=true,                % sets automatic line breaking
		breakatwhitespace=false,  % sets if automatic breaks should only happen at
		showspaces=false,
		showstringspaces=false}
		
		\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
OWLSearchEngine search = OWLSearchEngine.getInstance("example.owl","directory");
List<File> results = search.query("example/CL_City");
		\end{lstlisting}
		
		Die Fabrikmethode \emph{getInstance} erwartet als Parameter die zu verwendende Ontologie und das Suchverzeichnis. Beide können nachträglich über die Methoden \emph{bindOntology} bzw. \emph{setRootFolder} geändert werden:
		
		\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
search.bindOntology("ontologyPath");
search.setRootFolder("directoryPath");
		\end{lstlisting}
			\item \emph{Bearbeiten von Metadaten}: Ontologiebasierte Metadaten einer Datei können über die Klasse OWLMetaDataFile bearbeitet werden. Ihr Konstruktor erwartet als Parameter das File-Objekt der jeweiligen Datei. Für jede Datei wird eine eigene Instanz benötigt.
			
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
File file = new File("filePath");
OWLMetaDataFile metadata = new OWLMetaDataFile(file);
			\end{lstlisting}

Das erzeugte OWLMetaDataFile-Objekt ermöglicht folgende Funktionen:
			\begin{itemize}
			\item Über die Methode \emph{addOrReplaceTag} kann ein Tag hinzugefügt werden bzw. sein Zustand kann gesetzt werden. Sie erwartet drei Parameter: der Name des Tags, der Zustand und eine Ontologie, die für die Prüfung der Existenz von korrespondierenden OWL-Elementen eingesetzt wird. Im folgenden Beispiel wird ein existierendes Tag deaktiviert bzw. ein neues Tag im deaktiviertem Zustand angelegt:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
File owl = new File("myOntology.owl");
metadata.addOrReplaceTag("myOntology/CL_Country",false,owl);
			\end{lstlisting}
		\item Tags können mithilfe der Methode \emph{removeTag} entfernt werden:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
metadata.removeTag("example/IN_Afganistan");
			\end{lstlisting}
		\item Eine Kopie aller existierenden Tags und ihrer Zustände in einer Map wird von der Methode \emph{getCopyOfAllTags} zurückgeliefert:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
Map<String,Boolean> tags = metadata.getCopyOfAllTags();
			\end{lstlisting}
			\item Die Metadaten einer Datei können mithilfe der Methode \emph{synchronyzeWithOntology} mit Individuen und Klassen einer Ontologie zusammengeführt werden (s. Abschnitt \ref{Vorgehensweise bei der Beschreibung der Dateien}). Ein solcher Aufruf könnte wie folgt aussehen:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
File ontology = new File("ontology.owl");
metadata.synchronyzeWithOntology(ontology));
			\end{lstlisting}
			\end{itemize}		
			
			\item \emph{Extrahieren von IPTC-Metadaten}: IPTC-Metadaten können mithilfe eines IPTCMetaDataExtractor-Objektes aus Bilddateien extrahiert werden. Bei der Instanziierung müssen eine OWL-Ontologie und ein Verzeichnis mit den zu bearbeitenden Dateien als Parameter übergeben werden:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
File ontology = new File("ontology.owl");
File dir = new File("extractionDirectory");
IPTCMetaDataExtractor extractor = IPTCMetaDataExtractor(ontology, dir);
			\end{lstlisting}
			Die Methode \emph{extractIPTCMetaData} startet die Extraktion:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
ExtractionStatistic statistic = extractor.extractIPTCMetaData();
			\end{lstlisting}
			Als Ergebnis wird ein ExtractionStatistic-Objekt zurückgeliefert, das folgende Informationen enthält:
			\begin{itemize}
			\item Anzahl der Dateien, deren ontologiebasierte Metadaten erweitert wurden,
			\item Anzahl der Dateien, für die ontologiebasierte Metadaten angelegt wurden,
			\item Anzahl der erweiterten .ose-Dateien,
			\item eine für die Ausgabe formatierte Liste der extrahierten Metadatentags mit Angabe der Dateien und
			\item eine für die Ausgabe formatierte Liste der automatisch aktivierten Tags mit Angabe der Dateien.		
			\end{itemize}
			Die Ontologie und das Verzeichnis können nachträglich über die Methoden  \emph{setOwlOntology} und \emph{setDirectory} umkonfiguriert werden:
			\begin{lstlisting}[basicstyle=\ttfamily\bfseries]
extractor.setOwlOntology(new File("ontology.owl"));
extractor.setDirectory(new File("dir"));
			\end{lstlisting}
		\end{itemize}

	
\subsection{Verwendete Bibliotheken}
\label{Verwendete Bibliotheken}

In der Anwendung werden folgende Bibliotheken eingesetzt:

\begin{itemize}
\item geonames-1.1.9.jar - eine Client-Bibliothek von geonames.org \autocite{url:GeoNames}.
\item owlapi-bin.jar - Open Source OWL API zur Erzeugung, Manipulation und Serialisierung von OWL-Ontologien\autocite{art:owlapi}.
\item jdom-1.0.jar - javabasierte Lösung für den Zugriff, die Manipulation und die Ausgabe von XML Daten\autocite{url:jdom}.
\item commons-io-1.3.2.jar - eine Bibliothek zur Unterstützung von IO-Operationen \autocite{url:commonsio}.
\item miglayout-swing-4.2.jar - freier Open-Source-Java-Layoutmanager für Swing, SWT und JavaFX\autocite{url:miglayout}.
\item metadata-extractor-2.6.2.jar -  Metadata Extractor für Bilddateien\autocite{url:metadataextraktor}.
\end{itemize}

\newpage	
\section{Zusammenfassung}
\label{Zusammenfassung}

	Der Ausgangspunkt für diese Arbeit war die Idee, das in \autocite{art:semanticFileSystemSIL} präsentierte semantische Dateisystem SIL dadurch zu verbessern, dass bei der Suche die Bedeutung von Tags durch den Einsatz von Ontologien verwendet wird. Dabei mussten Taxonomien und nicht-hierarchische Beziehungen zwischen Tags vom Suchsystem in Betracht gezogen werden sowie das Problem der richtigen Interpretation von Synonymen und Homonymen gelöst werden. Anstatt eine konkrete Lösung für SIL zu entwickeln, wurde nach einer allgemeinen Lösung für ontologiebasiertes Suchen nach Dateien gesucht. Die gewonnenen Erkenntnisse können später für die Verbesserung der Suchergebnisse innerhalb von SIL adaptiert werden.

	Somit war das Ziel der vorliegenden Arbeit die Erstellung eines Konzeptes für ontologiebasierte Suche nach Dateien. Durch den Einsatz von Ontologien sollte das Konzept Taxonomien und nicht-hierarchische Beziehungen zwischen Begriffen berücksichtigen sowie Probleme bei der Interpretation der Semantik von Synonymen und Homonymen lösen.
	
	Das Ergebnis dieser Arbeit ist ein Konzept zur Suche nach Dateien mithilfe von Ontologien, von ontologiebasierten Metadaten und der entwickelten Anfragesprache DOQL. Die Schlüsselidee des Konzeptes besteht darin, dass die Metadaten und die Anfragesprache auf denselben Ontologien basieren. Dies stellt eine möglichst eindeutige maschinelle Interpretation der Semantik sowohl der Metadaten als auch der Anfragen sicher. Das Konzept wurde in Form eines Prototyps implementiert, der zur Evaluation der Anwendbarkeit des Konzepts eingesetzt werden kann.
		
	In der Einleitung zu dieser Arbeit wurden drei Probleme der musterbasierten Suche genannt, die durch den Einsatz von Ontologien gelöst werden konnten:
	\begin{enumerate}
		\item Hierarchische oder \emph{ist-ein}-Beziehungen zwischen Begriffen einer
		Wissensdomäne innerhalb der Metadaten und der Suchanfragen werden nicht erkannt und nicht ausgenutzt, obwohl sie großes Potenzial für unscharfe Suche bieten.
		\item Nicht-hierarchische Beziehungen zwischen Begriffen in Metadaten und Suchanfragen
		wurden nicht ausgenutzt. Sie könnten als Einschränkung bei der gezielten Suche
		eingesetzt werden.
		\item Synonyme Begriffe in Metadaten und in Suchanfragen können nicht wie Begriffe mit
		gleicher oder ähnlicher Semantik behandelt werden. Die Semantik homonymer Begriffe kann
		nicht erkannt werden. Dabei kann die Berücksichtigung von Synonymen und Homonymen kann
		die Suchqualität steigern.
	\end{enumerate}
	
	Das entwickelte Konzept bietet Lösungen für die drei aufgezählten Probleme. Es nutzt Hierarchien von Begriffen in Metadaten und Suchanfragen und erhöht somit die Qualität der unscharfen Suche. Dafür werden Klassen in den Ontologien verwendet. Die \emph{nicht} hierarchischen Beziehungen zwischen Begriffen werden in OWL-Ontologien mithilfe der Individuen-Eigenschaften definiert und über DOQL-Eigenschaftsfilter bei der gezielten Suche berücksichtigt. Das Problem der Synonyme konnte dank der in OWL eingebauten Eigenschaft \emph{owl:sameAs} gelöst werden. Die Semantik von Homonymen kann durch die Zuordnung von homonymen Begriffen unterschiedlichen Ontologien und durch die Verwendung von Ontologie-Präfixen in Tags richtig interpretiert werden.

	Als zusätzliches Ergebnis wurde eine Lösung zum Extrahieren von standardisierten Metadaten, ihre automatische Erweiterung durch die Verwendung vordefinierter Ontologien und die Integration von extrahierten Metadaten in das ontologiebasierte Suchsystem entwickelt.
		
	Das entwickelte Konzept bietet zwar gute Ergebnisse sowohl bei der gezielten, als auch bei der unscharfen Suche, aber es bringt auch Nachteile für den Benutzer mit sich. Dazu gehören:
	\begin{itemize}
		\item die Notwendigkeit eigene domänenspezifische Ontologien zu erstellen statt
		existierende zu
		verwenden um bessere Suchergebnisse zu erzielen und
		\item eine aufwendige Pflege der Metadaten, die gute Kenntnisse über OWL-Ontologien
		und	Kenntnisse über den Aufbau der verwendeten Ontologien voraussetzt.
	\end{itemize}
	
	Aufgrund der aufgezählten Nachteile eignet sich das Konzept vor allem für große und thematisch spezielle  Dateisammlungen, die lange Zeit benutzt werden und für die die Qualität der Suchergebnisse große Bedeutung hat. Das können beispielsweise professionelle Sammlungen von Multimediadateien sein. In dem Fall wird sich der Aufwand für die Beschreibung der Dateieninhalte, die Erstellung und Pflege spezieller Ontologien sowie die Nutzung der formalen Anfragesprache DOQL anstelle von Stichwörtern lohnen.
	
	Das im Rahmen dieser Arbeit entwickelte Konzept kann für das semantische Dateisystem SIL adaptiert werden. Dabei können Funktionen des Prototyps über die bereitgestellte Programmierschnittstelle genutzt werden.
	
	Außerdem kann auch das Konzept selbst erweitert und verbessert werden. So könnte zum Beispiel die Anfragesprache DOQL, durch die Erhöhung der Mächtigkeit bei Anfragen oder durch weitere Filter verbessert werden. Denkbar wäre ein Filter für die unscharfe Suche, der als Parameter beliebige Zeichenketten akzeptiert. Die Parameter würden dann bei der Extraktion semantisch passender Tags aus den Ontologien durch die Anwendung der patternbasierten Suche eingesetzt. Dabei muss eine passende Strategie für die Extraktion entwickelt werden, damit die Qualität von unscharfen Suchergebnissen sichergestellt wird. Denkbar ist außerdem die Behandlung von Tippfehlern bei der Interpretation von DOQL-Suchanfragen.
	
	Auch die Extraktionskomponente für standardisierte Metadaten kann weiterentwickelt werden. Der entwickelte Prototyp unterstützt nur das Extrahieren von IPTC-Metadaten und die Gewinnung von neuen, semantisch passenden geographischen Daten aus einer vordefinierten Ontologie. Eine Erweiterung bezüglich der unterstützten Dateiformate bzw. der Metadaten-Standards wäre ebenso sinnvoll wie die Verarbeitung weiterer Metadaten analog zu den geographischen (wie z.B. Zeitangaben, geographische Koordinaten).
	

\newpage
\addcontentsline{toc}{section}{Literatur} 
\printbibliography

%\newpage
%\appendix
%\addpart{Anhang}
	%\section{CD: Prototyp-Anwendung, Testdaten und Demotests}
\end{document}

